root
/
elasticsearch
mirror of https://github.com/elastic/elasticsearch.git
1
0
Fork 0
Code Issues Actions 1 Packages Projects Releases Wiki Activity
elasticsearch/server/src/main/java/module-info.java

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

482 lines
24 KiB
Java
Raw Normal View History

Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
Add AGPLv3 as a supported license
2024-09-14 04:28:03 +08:00
* or more contributor license agreements. Licensed under the "Elastic License
* 2.0", the "GNU Affero General Public License v3.0 only", and the "Server Side
* Public License v 1"; you may not use this file except in compliance with, at
* your election, the "Elastic License 2.0", the "GNU Affero General Public
* License v3.0 only", or the "Server Side Public License, v 1".
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
*/
Extensible Completion Postings Formats (#111494) Allows the Completion Postings Format to be extensible by providing an implementation of the CompletionsPostingsFormatExtension SPIs.
2024-11-29 05:25:02 +08:00
import org.elasticsearch.internal.CompletionsPostingsFormatExtension;
Make cat actions list extensible (#99504) This commit adds an internal extension for controlling which cat actions are returned by /_cat.
2023-09-14 11:48:09 +08:00
import org.elasticsearch.plugins.internal.RestExtension;
TSDB numeric compression (#92045) This doc values format is meant to be used for TSDB. It provides compression using delta encoding, gcd encoding and bit-packing encoding. The expectation is that such encoding works well for fields whose values are monotonically increasing, like the timestamp field and counter metric fields. Encoding and decoding fields using the new format is available behind a feature flag.
2023-01-12 22:42:49 +08:00
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
/** The Elasticsearch Server Module. */
module org.elasticsearch.server {
requires java.logging;
requires java.security.jgss;
requires java.sql;
requires java.management;
requires jdk.unsupported;
Upgrade geoip2 dependency (#93522)
2023-02-07 21:18:25 +08:00
requires java.net.http; // required by ingest-geoip's dependency maxmind.geoip2 https://github.com/elastic/elasticsearch/issues/93553
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
requires org.elasticsearch.cli;
requires org.elasticsearch.base;
Add native access library (#105100) Elasticsearch requires access to some native functions. Historically this has been achieved with the JNA library. However, JNA is a complicated, magical library, and has caused various problems booting Elasticsearch over the years. The new Java Foreign Function and Memory API allows access to call native functions directly from Java. It also has the advantage of tight integration with hotspot which can improve performance of these functions (though performance of Elasticsearch's native calls has never been much of an issue since they are mostly at boot time). This commit adds a new native lib that is internal to Elasticsearch. It is built to use the foreign function api starting with Java 21, and continue using JNA with Java versions below that. Only one function, checking whether Elasticsearch is running as root, is migrated. Future changes will migrate other native functions.
2024-02-08 07:27:09 +08:00
requires org.elasticsearch.nativeaccess;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
requires org.elasticsearch.geo;
requires org.elasticsearch.lz4;
requires org.elasticsearch.securesm;
requires org.elasticsearch.xcontent;
Stable logging API - the basic use case (#86612) Introducing a stable logging API under libs/logging. This change covers the most common use cases for logging: fetching a logger with LogManager, emitting a log messages with Logger and Level. It is influenced by log4j2-api, but do not include Marker and LogBuilder methods. Also methods using org.apache.logging.log4j.util.Supplier are replaced with java.util.Supplier The basic implementation is present in server and injected statically in LogConfigurator relates #84478
2022-06-13 16:25:54 +08:00
requires org.elasticsearch.logging;
[Stable plugin api] Drop api suffix in package names (#92905) Refactoring that drops the api suffix from package name This will have to be followed up by a plugins/examples fix in imports Also set an artifact group name to `org.elasticsearch.plugin` in the plugin-api and plugin-analysis-api
2023-01-14 16:49:37 +08:00
requires org.elasticsearch.plugin;
requires org.elasticsearch.plugin.analysis;
Move redact ingest processor into x-pack (#95426)
2023-04-22 03:04:49 +08:00
requires org.elasticsearch.grok;
Fork TDigest library (#96086) * Initial import for TDigest forking. * Fix MedianTest. More work needed for TDigestPercentile*Tests and the TDigestTest (and the rest of the tests) in the tdigest lib to pass. * Fix Dist. * Fix AVLTreeDigest.quantile to match Dist for uniform centroids. * Update docs/changelog/96086.yaml * Fix `MergingDigest.quantile` to match `Dist` on uniform distribution. * Add merging to TDigestState.hashCode and .equals. Remove wrong asserts from tests and MergingDigest. * Fix style violations for tdigest library. * Fix typo. * Fix more style violations. * Fix more style violations. * Fix remaining style violations in tdigest library. * Update results in docs based on the forked tdigest. * Fix YAML tests in aggs module. * Fix YAML tests in x-pack/plugin. * Skip failing V7 compat tests in modules/aggregations. * Fix TDigest library unittests. Remove redundant serializing interfaces from the library. * Remove YAML test versions for older releases. These tests don't address compatibility issues in mixed cluster tests as the latter contain a mix of older and newer nodes, so the output depends on which node is picked as a data node since the forked TDigest library is not backwards compatible (produces slightly different results). * Fix test failures in docs and mixed cluster. * Reduce buffer sizes in MergingDigest to avoid oom. * Exclude more failing V7 compatibility tests. * Update results for JdbcCsvSpecIT tests. * Update results for JdbcDocCsvSpecIT tests. * Revert unrelated change. * More test fixes. * Use version skips instead of blacklisting in mixed cluster tests. * Switch TDigestState back to AVLTreeDigest. * Update docs and tests with AVLTreeDigest output. * Update flaky test. * Remove dead code, esp around tracking of incoming data. * Update docs/changelog/96086.yaml * Delete docs/changelog/96086.yaml * Remove explicit compression calls. This was added to prevent concurrency tests from failing, but it leads to reduces precision. Submit this to see if the concurrency tests are still failing. * Revert "Remove explicit compression calls." This reverts commit 5352c96f656b9cdc63f0f673c983150bea35c7ed. * Remove explicit compression calls to MedianAbsoluteDeviation input. * Add unittests for AVL and merging digest accuracy. * Fix spotless violations. * Delete redundant tests and benchmarks. * Fix spotless violation. * Use the old implementation of AVLTreeDigest. The latest library version is 50% slower and less accurate, as verified by ComparisonTests. * Update docs with latest percentile results. * Update docs with latest percentile results. * Remove repeated compression calls. * Update more percentile results. * Use approximate percentile values in integration tests. This helps with mixed cluster tests, where some of the tests where blocked. * Fix expected percentile value in test. * Revert in-place node updates in AVL tree. Update quantile calculations between centroids and min/max values to match v.3.2. * Add SortingDigest and HybridDigest. The SortingDigest tracks all samples in an ArrayList that gets sorted for quantile calculations. This approach provides perfectly accurate results and is the most efficient implementation for up to millions of samples, at the cost of bloated memory footprint. The HybridDigest uses a SortingDigest for small sample populations, then switches to a MergingDigest. This approach combines to the best performance and results for small sample counts with very good performance and acceptable accuracy for effectively unbounded sample counts. * Remove deps to the 3.2 library. * Remove unused licenses for tdigest. * Revert changes for SortingDigest and HybridDigest. These will be submitted in a follow-up PR for enabling MergingDigest. * Remove unused Histogram classes and unit tests. Delete dead and commented out code, make the remaining tests run reasonably fast. Remove unused annotations, esp. SuppressWarnings. * Remove Comparison class, not used. * Small fixes. * Add javadoc and tests. * Remove special logic for singletons in the boundaries. While this helps with the case where the digest contains only singletons (perfect accuracy), it has a major issue problem (non-monotonic quantile function) when the first singleton is followed by a non-singleton centroid. It's preferable to revert to the old version from 3.2; inaccuracies in a singleton-only digest should be mitigated by using a sorted array for small sample counts. * Revert changes to expected values in tests. This is due to restoring quantile functions to match head. * Revert changes to expected values in tests. This is due to restoring quantile functions to match head. * Tentatively restore percentile rank expected results. * Use cdf version from 3.2 Update Dist.cdf to use interpolation, use the same cdf version in AVLTreeDigest and MergingDigest. * Revert "Tentatively restore percentile rank expected results." This reverts commit 7718dbba594f068913dfb7b85f488ca25e5e47bf. * Revert remaining changes compared to main. * Revert excluded V7 compat tests. * Exclude V7 compat tests still failing. * Exclude V7 compat tests still failing. * Restore bySize function in TDigest and subclasses.
2023-06-13 16:43:54 +08:00
requires org.elasticsearch.tdigest;
Rename the vec module to better reflect that it provides SIMD optimized vector scorers (#109661) This commit renames the vector module to better reflect its intent - to provide SIMD optimized vector scorer implementations.
2024-06-17 18:10:02 +08:00
requires org.elasticsearch.simdvec;
Dynamic entitlement agent (#116125) * Refactor: treat "maybe" JVM options uniformly * WIP * Get entitlement running with bridge all the way through, with qualified exports * Cosmetic changes to SystemJvmOptions * Disable entitlements by default * Bridge module comments * Fixup forbidden APIs * spotless * Rename EntitlementChecker * Fixup InstrumenterTests * exclude recursive dep * Fix some compliance stuff * Rename asm-provider * Stop using bridge in InstrumenterTests * Generalize readme for asm-provider * InstrumenterTests doesn't need EntitlementCheckerHandle * Better javadoc * Call parseBoolean * Add entitlement to internal module list * Docs as requested by Lorenzo * Changes from Jack * Rename ElasticsearchEntitlementChecker * Remove logging javadoc * exportInitializationToAgent should reference EntitlementInitialization, not EntitlementBootstrap. They're currently in the same module, but if that ever changes, this code would have become wrong. * Some suggestions from Mark --------- Co-authored-by: Ryan Ernst <ryan@iernst.net>
2024-11-06 07:07:52 +08:00
requires org.elasticsearch.entitlement;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
requires hppc;
requires HdrHistogram;
requires jopt.simple;
requires log4j2.ecs.layout;
requires org.lz4.java;
requires org.apache.logging.log4j;
requires org.apache.logging.log4j.core;
requires org.apache.lucene.analysis.common;
requires org.apache.lucene.backward_codecs;
requires org.apache.lucene.core;
requires org.apache.lucene.grouping;
requires org.apache.lucene.highlighter;
requires org.apache.lucene.join;
requires org.apache.lucene.memory;
requires org.apache.lucene.misc;
requires org.apache.lucene.queries;
requires org.apache.lucene.queryparser;
requires org.apache.lucene.sandbox;
requires org.apache.lucene.suggest;
exports org.elasticsearch;
exports org.elasticsearch.action;
exports org.elasticsearch.action.admin.cluster.allocation;
exports org.elasticsearch.action.admin.cluster.configuration;
Add o.e.a.a.cluster.coordination to exports from server (#92059) Fixes the red squigglies in IntelliJ.
2022-12-12 17:23:15 +08:00
exports org.elasticsearch.action.admin.cluster.coordination;
Make Desired Nodes API operator-only (#87778) * Remove Desired Nodes API from NON_OPERATOR_ACTIONS * Add desired nodes to the operator privileges test * Add desired nodes privileges integration tests Resolves #87777.
2022-06-20 21:32:44 +08:00
exports org.elasticsearch.action.admin.cluster.desirednodes;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.action.admin.cluster.health;
exports org.elasticsearch.action.admin.cluster.migration;
Add a capabilities API to check node and cluster capabilities (#106820) This adds a /_capabilities rest endpoint for checking the capabilities of a cluster - what endpoints, parameters, and endpoint capabilities the cluster supports
2024-05-08 21:44:26 +08:00
exports org.elasticsearch.action.admin.cluster.node.capabilities;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.action.admin.cluster.node.hotthreads;
exports org.elasticsearch.action.admin.cluster.node.info;
exports org.elasticsearch.action.admin.cluster.node.reload;
Prevalidate node removal API (pt. 1) (#88952) This PR adds the first part of the Prevalidate Node Removal API. This API allows checking whether attempting to remove some node(s) from the cluster is likely to succeed or not. This check is useful when a node needs to be removed from a RED cluster, without risking loosing the last copy of some RED shards. In this PR, we only check whether a RED index is a Searchable Snapshot index or not, in which case the removal of any node is safe as the RED index is backed by a snapshot. Relates #87776
2022-11-16 20:44:00 +08:00
exports org.elasticsearch.action.admin.cluster.node.shutdown;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.action.admin.cluster.node.stats;
exports org.elasticsearch.action.admin.cluster.node.tasks.cancel;
exports org.elasticsearch.action.admin.cluster.node.tasks.get;
exports org.elasticsearch.action.admin.cluster.node.tasks.list;
exports org.elasticsearch.action.admin.cluster.node.usage;
exports org.elasticsearch.action.admin.cluster.remote;
exports org.elasticsearch.action.admin.cluster.repositories.cleanup;
exports org.elasticsearch.action.admin.cluster.repositories.delete;
exports org.elasticsearch.action.admin.cluster.repositories.get;
exports org.elasticsearch.action.admin.cluster.repositories.put;
exports org.elasticsearch.action.admin.cluster.repositories.verify;
exports org.elasticsearch.action.admin.cluster.reroute;
exports org.elasticsearch.action.admin.cluster.settings;
exports org.elasticsearch.action.admin.cluster.shards;
exports org.elasticsearch.action.admin.cluster.snapshots.clone;
exports org.elasticsearch.action.admin.cluster.snapshots.create;
exports org.elasticsearch.action.admin.cluster.snapshots.delete;
exports org.elasticsearch.action.admin.cluster.snapshots.features;
exports org.elasticsearch.action.admin.cluster.snapshots.get;
exports org.elasticsearch.action.admin.cluster.snapshots.get.shard;
exports org.elasticsearch.action.admin.cluster.snapshots.restore;
exports org.elasticsearch.action.admin.cluster.snapshots.status;
exports org.elasticsearch.action.admin.cluster.state;
exports org.elasticsearch.action.admin.cluster.stats;
exports org.elasticsearch.action.admin.cluster.storedscripts;
exports org.elasticsearch.action.admin.cluster.tasks;
exports org.elasticsearch.action.admin.indices.alias;
exports org.elasticsearch.action.admin.indices.alias.get;
exports org.elasticsearch.action.admin.indices.analyze;
exports org.elasticsearch.action.admin.indices.cache.clear;
exports org.elasticsearch.action.admin.indices.close;
exports org.elasticsearch.action.admin.indices.create;
exports org.elasticsearch.action.admin.indices.dangling;
exports org.elasticsearch.action.admin.indices.dangling.delete;
exports org.elasticsearch.action.admin.indices.dangling.find;
exports org.elasticsearch.action.admin.indices.dangling.import_index;
exports org.elasticsearch.action.admin.indices.dangling.list;
exports org.elasticsearch.action.admin.indices.delete;
exports org.elasticsearch.action.admin.indices.diskusage;
exports org.elasticsearch.action.admin.indices.flush;
exports org.elasticsearch.action.admin.indices.forcemerge;
exports org.elasticsearch.action.admin.indices.get;
exports org.elasticsearch.action.admin.indices.mapping.get;
exports org.elasticsearch.action.admin.indices.mapping.put;
exports org.elasticsearch.action.admin.indices.open;
exports org.elasticsearch.action.admin.indices.readonly;
exports org.elasticsearch.action.admin.indices.recovery;
exports org.elasticsearch.action.admin.indices.refresh;
exports org.elasticsearch.action.admin.indices.resolve;
exports org.elasticsearch.action.admin.indices.rollover;
exports org.elasticsearch.action.admin.indices.segments;
exports org.elasticsearch.action.admin.indices.settings.get;
exports org.elasticsearch.action.admin.indices.settings.put;
exports org.elasticsearch.action.admin.indices.shards;
exports org.elasticsearch.action.admin.indices.shrink;
exports org.elasticsearch.action.admin.indices.stats;
exports org.elasticsearch.action.admin.indices.template.delete;
exports org.elasticsearch.action.admin.indices.template.get;
exports org.elasticsearch.action.admin.indices.template.post;
exports org.elasticsearch.action.admin.indices.template.put;
exports org.elasticsearch.action.admin.indices.validate.query;
exports org.elasticsearch.action.bulk;
exports org.elasticsearch.action.datastreams;
exports org.elasticsearch.action.delete;
exports org.elasticsearch.action.explain;
exports org.elasticsearch.action.fieldcaps;
exports org.elasticsearch.action.get;
exports org.elasticsearch.action.index;
exports org.elasticsearch.action.ingest;
exports org.elasticsearch.action.resync;
exports org.elasticsearch.action.search;
exports org.elasticsearch.action.support;
exports org.elasticsearch.action.support.broadcast;
exports org.elasticsearch.action.support.broadcast.node;
New TransportBroadcastUnpromotableAction action (#93600) Introduces: * New action that can be used to broadcast to unpromotable shards of a given IndexShardRoutingTable. * New hook in ReplicationOperation for custom logic when the primary operation completes. If there is a failure, this increases the shard failures of the replication operation. * Refresh action now uses the new hook to broadcast the unpromotable refresh action to all unpromotable shards. Fixes ES-5454 Fixes ES-5212
2023-02-15 18:46:06 +08:00
exports org.elasticsearch.action.support.broadcast.unpromotable;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.action.support.master;
exports org.elasticsearch.action.support.master.info;
exports org.elasticsearch.action.support.nodes;
Make TransportLocalClusterStateAction wait for cluster to unblock (#117230) This will make `TransportLocalClusterStateAction` wait for a new state that is not blocked. This means we need a timeout (again). For consistency's sake, we're reusing the REST param `master_timeout` for this timeout as well. The only class that was using `TransportLocalClusterStateAction` was `TransportGetAliasesAction`, so its request needed to accept a timeout again as well.
2024-12-04 19:17:13 +08:00
exports org.elasticsearch.action.support.local;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.action.support.replication;
exports org.elasticsearch.action.support.single.instance;
exports org.elasticsearch.action.support.single.shard;
exports org.elasticsearch.action.support.tasks;
exports org.elasticsearch.action.termvectors;
exports org.elasticsearch.action.update;
exports org.elasticsearch.bootstrap;
exports org.elasticsearch.client.internal;
exports org.elasticsearch.client.internal.node;
exports org.elasticsearch.client.internal.support;
exports org.elasticsearch.client.internal.transport;
exports org.elasticsearch.cluster;
exports org.elasticsearch.cluster.action.index;
exports org.elasticsearch.cluster.action.shard;
exports org.elasticsearch.cluster.block;
exports org.elasticsearch.cluster.coordination;
Make some AtomicRegisterCoordinatorTests classes public for reuse (#94936)
2023-03-31 19:27:46 +08:00
exports org.elasticsearch.cluster.coordination.stateless;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.cluster.health;
exports org.elasticsearch.cluster.metadata;
exports org.elasticsearch.cluster.node;
exports org.elasticsearch.cluster.routing;
exports org.elasticsearch.cluster.routing.allocation;
exports org.elasticsearch.cluster.routing.allocation.allocator;
exports org.elasticsearch.cluster.routing.allocation.command;
exports org.elasticsearch.cluster.routing.allocation.decider;
exports org.elasticsearch.cluster.service;
Wrap transport version in cluster state (#99114) Cluster state currently holds a cluster minimum transport version and a map of nodes to transport versions. However, to determine node compatibility, we will need to account for more types of versions in cluster state than just the transport version (see #99076). Here we introduce a wrapper class to cluster state and update accessors and builders to use the new method. (I would have liked to re-use org.elasticsearch.cluster.node.VersionInformation, but that one holds IndexVersion rather than TransportVersion. * Introduce CompatibilityVersions to cluster state class
2023-09-06 21:52:42 +08:00
exports org.elasticsearch.cluster.version;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.common;
exports org.elasticsearch.common.blobstore;
exports org.elasticsearch.common.blobstore.fs;
exports org.elasticsearch.common.blobstore.support;
exports org.elasticsearch.common.breaker;
exports org.elasticsearch.common.bytes;
exports org.elasticsearch.common.cache;
exports org.elasticsearch.common.cli;
exports org.elasticsearch.common.collect;
exports org.elasticsearch.common.component;
exports org.elasticsearch.common.compress;
exports org.elasticsearch.common.document;
Move AbstractFileWatchingService to a common package for export (#95238) * Move AbstractFileWatchingService to a common package * Export the new package * Clean up tests and member visibility
2023-04-21 01:14:26 +08:00
exports org.elasticsearch.common.file;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.common.geo;
exports org.elasticsearch.common.hash;
New injector (#111722) * Initial new injector * Allow createComponents to return classes * Downsample injection * Remove more vestiges of subtype handling * Lowercase logger * Respond to code review comments * Only one object per class * Some additional cleanup incl spotless * PR feedback * Missed one * Rename workQueue * Remove Injector.addRecordContents * TelemetryProvider requires us to inject an object using a supertype * Address Simon's comments * Clarify the reason for SuppressForbidden * Make log indentation code less intrusive
2024-08-28 23:13:47 +08:00
exports org.elasticsearch.injection.api;
Move Guice to org.elasticsearch.injection.guice (#111723) * Move files and fix imports & module exports * Other consequences of moving Guice
2024-08-12 22:47:46 +08:00
exports org.elasticsearch.injection.guice;
exports org.elasticsearch.injection.guice.binder;
exports org.elasticsearch.injection.guice.internal;
exports org.elasticsearch.injection.guice.matcher;
exports org.elasticsearch.injection.guice.multibindings;
exports org.elasticsearch.injection.guice.name;
exports org.elasticsearch.injection.guice.spi;
exports org.elasticsearch.injection.guice.util;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.common.io;
exports org.elasticsearch.common.io.stream;
exports org.elasticsearch.common.logging;
exports org.elasticsearch.common.lucene;
exports org.elasticsearch.common.lucene.index;
exports org.elasticsearch.common.lucene.search;
exports org.elasticsearch.common.lucene.search.function;
exports org.elasticsearch.common.lucene.store;
exports org.elasticsearch.common.lucene.uid;
exports org.elasticsearch.common.metrics;
exports org.elasticsearch.common.network;
exports org.elasticsearch.common.path;
exports org.elasticsearch.common.recycler;
exports org.elasticsearch.common.regex;
Move SchedulerEngine and TimeValueSchedule to server/common/scheduler (#93862) We built quite a bit of infrastructure to have one polling job running via the `SchedulerEngine` and `ActiveSchedule`. This moves this infrastructure outside x-pack to server so elasticsearch/modules can use it and avoid re-implementing it using `threadPool.schedule`.
2023-02-17 16:55:40 +08:00
exports org.elasticsearch.common.scheduler;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.common.settings;
exports org.elasticsearch.common.text;
exports org.elasticsearch.common.time;
exports org.elasticsearch.common.transport;
exports org.elasticsearch.common.unit;
exports org.elasticsearch.common.util;
exports org.elasticsearch.common.util.concurrent;
exports org.elasticsearch.common.util.iterable;
exports org.elasticsearch.common.util.set;
exports org.elasticsearch.common.xcontent;
exports org.elasticsearch.common.xcontent.support;
exports org.elasticsearch.discovery;
exports org.elasticsearch.env;
Create new feature API for querying features present on a cluster (#100974) This adds an internal API and service to manage & get information on features that are present on nodes in a cluster. New features can be declared as supported, and historical features can be added to previous node versions to eventually replace node version comparisons
2023-10-30 22:38:30 +08:00
exports org.elasticsearch.features;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.gateway;
exports org.elasticsearch.health;
Health API - Monitoring local disk health (#88390) This PR introduces the local health monitoring functionality needed for #84811 . The monitor uses the `NodeService` to get the disk usage stats and determines the node's disk health. When a change in the disk's is detected or when the health node changes, this class would be responsible to send the node's health to the health node. Currently this is simulated with a method that just logs the current health. The monitor keeps the last reported health, this way, if something fails on the next check it will try to resend the new health state.
2022-08-03 16:10:26 +08:00
exports org.elasticsearch.health.node;
Extend `repository_integrity` health indicator for unknown and invalid repos (#104614) This PR extends the repository integrity health indicator to cover also unknown and invalid repositories. Because these errors are local to a node, we extend the `LocalHealthMonitor` to monitor the repositories and report the changes in their health regarding the unknown or invalid status. To simplify this extension in the future, we introduce the `HealthTracker` abstract class that can be used to create new local health checks. Furthermore, we change the severity of the health status when the repository integrity indicator reports unhealthy from `RED` to `YELLOW` because even though this is a serious issue, there is no user impact yet.
2024-02-07 22:18:55 +08:00
exports org.elasticsearch.health.node.tracker;
Do not wait for the health node task (#87830) The health node task is a permanent task, for this reason it doesn't make sense to wait for it in a method that waits for pending tasks. This fixes that.
2022-06-20 17:48:59 +08:00
exports org.elasticsearch.health.node.selection;
Collect health API stats (#91559) This PR introduces the collectors of the health API telemetry. Our target telemetry has the following shape: ``` { "invocations": { "total": 22, "verbose_true": 12, "verbose_false": 10 }, "statuses": { "green": 10, "yellow": 4, "red": 8, "values": ["green", "yellow", "red"] }, "indicators": { "red" : { "master_stability": 2, "ilm":2, "slm": 4, "values": ["master_stability", "ilm", "slm"] }, "yellow": { "disk": 1, "shards_availability": 1, "master_stability": 2, "values": ["disk", "shards_availability", "master_stability"] } }, "diagnoses": { "red": { "elasticsearch:health:shards_availability:primary_unassigned": 1, "elasticsearch:health:disk:add_disk_capacity_master_nodes": 3, "values": ["elasticsearch:health:shards_availability:primary_unassigned", "elasticsearch:health:disk:add_disk_capacity_master_nodes"] }, "yellow": { "elasticsearch:health:disk:add_disk_capacity_data_nodes": 1, "values": [""elasticsearch:health:disk:add_disk_capacity_data_nodes"] } } } ``` This PR introduces the thread safe `Counters` class and the `HealthApiStats` which keeps keeps of the metrics above based on the health api responses that it encounters. The `HealthApiStatsAction` collects the `HealthApiStats` of all nodes. Part of: #90877
2022-11-18 18:34:33 +08:00
exports org.elasticsearch.health.stats;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.http;
exports org.elasticsearch.index;
exports org.elasticsearch.index.analysis;
exports org.elasticsearch.index.bulk.stats;
exports org.elasticsearch.index.cache;
exports org.elasticsearch.index.cache.bitset;
exports org.elasticsearch.index.cache.query;
exports org.elasticsearch.index.cache.request;
exports org.elasticsearch.index.codec;
TSDB numeric compression (#92045) This doc values format is meant to be used for TSDB. It provides compression using delta encoding, gcd encoding and bit-packing encoding. The expectation is that such encoding works well for fields whose values are monotonically increasing, like the timestamp field and counter metric fields. Encoding and decoding fields using the new format is available behind a feature flag.
2023-01-12 22:42:49 +08:00
exports org.elasticsearch.index.codec.tsdb;
Enable BloomFilter for _id of non-datastream indices (#88409) This PR adds BloomFilter to Elasticsearch and enables it for the _id field of non-data stream indices. BloomFilter should speed up the performance of mget and update requests at a small expense of refresh, merge, and storage.
2022-08-08 23:14:26 +08:00
exports org.elasticsearch.index.codec.bloomfilter;
Cut over stored fields to ZSTD for compression. (#103374) This cuts over stored fields with `index.codec: best_speed` (default) to ZSTD with level 0 and blocks of at most 128 documents or 14kB, and `index.codec: best_compression` to ZSTD with level 3 and blocks of at most 2,048 documents or 240kB. Compared with the current codecs, this would yield similar indexing speed, much better space efficiency and similar retrieval speed. Benchmarks on the `elastic/logs` track suggest 10% better storage efficiency and slightly faster ingestion. The Lucene codec infrastructure records the codec on a per-segment basis and ensures that this change is backward-compatible. Segments will get progressively migrated to ZSTD as they get merged in the background. Bindings for ZSTD are provided by the Panama FFI API on JDK21+ and JNA on older JDKs. ZSTD support is currently behind a feature flag, so it won't be enabled immediately when this feature gets merged, this will need a follow-up change. Co-authored-by: Mark Vieira <portugee@gmail.com> Co-authored-by: Ryan Ernst <ryan@iernst.net>
2024-04-09 15:18:58 +08:00
exports org.elasticsearch.index.codec.zstd;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.index.engine;
exports org.elasticsearch.index.fielddata;
exports org.elasticsearch.index.fielddata.fieldcomparator;
exports org.elasticsearch.index.fielddata.ordinals;
exports org.elasticsearch.index.fielddata.plain;
exports org.elasticsearch.index.fieldvisitor;
exports org.elasticsearch.index.flush;
exports org.elasticsearch.index.get;
exports org.elasticsearch.index.mapper;
exports org.elasticsearch.index.mapper.flattened;
Move kNN search and dense vectors to core (#87815) This PR moves kNN search and dense vector support out of an xpack plugin and into server. In #87625 we plan to integrate ANN search into the main `_search` endpoint as a new top-level component called `knn`. So kNN will be a dedicated part of the search request, and we'll have kNN logic within the search phases. The classes and logic will live in server, matching the other search components like suggesters, field collapsing, etc.
2022-06-23 12:10:20 +08:00
exports org.elasticsearch.index.mapper.vectors;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.index.merge;
exports org.elasticsearch.index.query;
exports org.elasticsearch.index.query.functionscore;
exports org.elasticsearch.index.query.support;
exports org.elasticsearch.index.recovery;
exports org.elasticsearch.index.refresh;
exports org.elasticsearch.index.reindex;
exports org.elasticsearch.index.search;
exports org.elasticsearch.index.search.stats;
exports org.elasticsearch.index.seqno;
exports org.elasticsearch.index.shard;
exports org.elasticsearch.index.similarity;
exports org.elasticsearch.index.snapshots;
exports org.elasticsearch.index.snapshots.blobstore;
exports org.elasticsearch.index.stats;
exports org.elasticsearch.index.store;
exports org.elasticsearch.index.termvectors;
exports org.elasticsearch.index.translog;
exports org.elasticsearch.index.warmer;
exports org.elasticsearch.indices;
exports org.elasticsearch.indices.analysis;
exports org.elasticsearch.indices.breaker;
exports org.elasticsearch.indices.cluster;
exports org.elasticsearch.indices.fielddata.cache;
exports org.elasticsearch.indices.recovery;
exports org.elasticsearch.indices.recovery.plan;
exports org.elasticsearch.indices.store;
[ML] Make Inference Services pluggable (#99886) Creates an InferenceServicePlugins interface for inference services to implement and adds a test implementation to mock an inference service.
2023-09-27 20:35:45 +08:00
exports org.elasticsearch.inference;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.ingest;
Make transport and index versions easier to extend (#99688) When overriding transport and index versions, it is difficult to decide whether a version constant in serverless should be returned, or the latest version constant from serverless should be used, since the latest from serverless is not available. This commit adjust the version extension methods to pass in the latest serverless version constants. It also tweaks module and method visibility for a helper method needed.
2023-09-20 21:15:04 +08:00
exports org.elasticsearch.internal
to
org.elasticsearch.serverless.version,
org.elasticsearch.serverless.buildinfo,
Extensible Completion Postings Formats (#111494) Allows the Completion Postings Format to be extensible by providing an implementation of the CompletionsPostingsFormatExtension SPIs.
2024-11-29 05:25:02 +08:00
org.elasticsearch.serverless.constants,
org.elasticsearch.serverless.codec;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.lucene.analysis.miscellaneous;
exports org.elasticsearch.lucene.grouping;
exports org.elasticsearch.lucene.queries;
exports org.elasticsearch.lucene.search.uhighlight;
exports org.elasticsearch.lucene.search.vectorhighlight;
exports org.elasticsearch.lucene.similarity;
exports org.elasticsearch.lucene.util;
exports org.elasticsearch.monitor;
exports org.elasticsearch.monitor.fs;
exports org.elasticsearch.monitor.jvm;
exports org.elasticsearch.monitor.os;
exports org.elasticsearch.monitor.process;
exports org.elasticsearch.node;
Add mechanism to react to termination signals (#95850) This commit adds a mechanism to be exposed internally to allow plugins/modules to react to termination signals via SPI. I'm not entirely sure how to test this - normally I'd use an `ESIntegTestCase` and supply a stubbed version of the plugin but that's more difficult with SPI. Supercedes https://github.com/elastic/elasticsearch/pull/95518
2023-05-18 05:18:37 +08:00
exports org.elasticsearch.node.internal to org.elasticsearch.internal.sigterm;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.persistent;
exports org.elasticsearch.persistent.decider;
exports org.elasticsearch.plugins;
Make RestController pluggable (#98187) This commit changes the ActionModules to allow the RestController to be provided by an internal plugin. It renames `RestInterceptorActionPlugin` to `RestServerActionPlugin` and adds a new `getRestController` method to it. There may be multiple RestServerActionPlugins installed on a node, but only 1 may provide a Rest Wrapper (getRestHandlerInterceptor) and only 1 may provide a RestController (getRestController).
2023-08-08 13:29:24 +08:00
exports org.elasticsearch.plugins.interceptor to org.elasticsearch.security, org.elasticsearch.serverless.rest;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.plugins.spi;
exports org.elasticsearch.repositories;
exports org.elasticsearch.repositories.blobstore;
exports org.elasticsearch.repositories.fs;
Add o.e.a.a.cluster.coordination to exports from server (#92059) Fixes the red squigglies in IntelliJ.
2022-12-12 17:23:15 +08:00
exports org.elasticsearch.reservedstate;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.rest;
exports org.elasticsearch.rest.action;
exports org.elasticsearch.rest.action.admin.cluster;
exports org.elasticsearch.rest.action.admin.cluster.dangling;
exports org.elasticsearch.rest.action.admin.indices;
exports org.elasticsearch.rest.action.cat;
exports org.elasticsearch.rest.action.document;
exports org.elasticsearch.rest.action.ingest;
exports org.elasticsearch.rest.action.search;
exports org.elasticsearch.script;
exports org.elasticsearch.script.field;
Move kNN search and dense vectors to core (#87815) This PR moves kNN search and dense vector support out of an xpack plugin and into server. In #87625 we plan to integrate ANN search into the main `_search` endpoint as a new top-level component called `knn`. So kNN will be a dedicated part of the search request, and we'll have kNN logic within the search phases. The classes and logic will live in server, matching the other search components like suggesters, field collapsing, etc.
2022-06-23 12:10:20 +08:00
exports org.elasticsearch.script.field.vectors;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.search;
exports org.elasticsearch.search.aggregations;
exports org.elasticsearch.search.aggregations.bucket;
exports org.elasticsearch.search.aggregations.bucket.composite;
Make counted terms agg visible to profiling (#105049) The counted-terms aggregation is defined in its own plugin. When other plugins (such as the profiling plugin) want to use this aggregation, this leads to class loader issues, such as that the aggregation class is not recognized. By moving just the aggregation code itself to the server module but keeping everything else (including registration) in the `mapper-counted-keyword` module, we can use the counted-terms aggregation also from other plugins.
2024-02-02 22:56:07 +08:00
exports org.elasticsearch.search.aggregations.bucket.countedterms;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.search.aggregations.bucket.filter;
exports org.elasticsearch.search.aggregations.bucket.geogrid;
exports org.elasticsearch.search.aggregations.bucket.global;
exports org.elasticsearch.search.aggregations.bucket.histogram;
exports org.elasticsearch.search.aggregations.bucket.missing;
exports org.elasticsearch.search.aggregations.bucket.nested;
exports org.elasticsearch.search.aggregations.bucket.range;
exports org.elasticsearch.search.aggregations.bucket.sampler;
Export random sampler agg from server (#104747) The server module exports the classes needed to use most aggregations, but the random sampler aggregation was missed. (I think it's because the PRs to add random sampler and to add modularization in general were both long-running and were in flight around the same time.) This PR adds an export for the random sampler agg, so that it can be used from plugins.
2024-01-25 21:01:35 +08:00
exports org.elasticsearch.search.aggregations.bucket.sampler.random;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.search.aggregations.bucket.terms;
exports org.elasticsearch.search.aggregations.bucket.terms.heuristic;
exports org.elasticsearch.search.aggregations.metrics;
exports org.elasticsearch.search.aggregations.pipeline;
exports org.elasticsearch.search.aggregations.support;
exports org.elasticsearch.search.aggregations.support.values;
exports org.elasticsearch.search.builder;
exports org.elasticsearch.search.collapse;
exports org.elasticsearch.search.dfs;
exports org.elasticsearch.search.fetch;
exports org.elasticsearch.search.fetch.subphase;
exports org.elasticsearch.search.fetch.subphase.highlight;
exports org.elasticsearch.search.internal;
exports org.elasticsearch.search.lookup;
exports org.elasticsearch.search.profile;
exports org.elasticsearch.search.profile.aggregation;
Add profiling and documentation for dfs phase (#90536) Adds profiling statistics for the dfs phase, and adds documentation for both the dfs phase profiling and kNN profiling. Closes #89713
2022-10-06 00:54:36 +08:00
exports org.elasticsearch.search.profile.dfs;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.search.profile.query;
exports org.elasticsearch.search.query;
Add support for Reciprocal Rank Fusion to the search API (#93396) This change at a high level adds global ranking on the coordinating node at the end of query reduction prior to the fetch phase. Individual rank methods are defined in plugins. The first rank plugin added as part of this change is reciprocal rank fusion (RRF). RRF uses a relatively simple formula for merging 1...n results sets together with sum(1/(k+d)) where k is a ranking constant and d is a document's scored position within a result set from a query.
2023-04-25 06:07:34 +08:00
exports org.elasticsearch.search.rank;
Adding new RankContext classes per different search phase/node type (#107093)
2024-04-24 19:58:16 +08:00
exports org.elasticsearch.search.rank.context;
Adding RankFeature implementation (#108538)
2024-06-06 16:20:53 +08:00
exports org.elasticsearch.search.rank.feature;
Adding RerankingContext classes to support global reranking (#109435)
2024-06-12 23:09:06 +08:00
exports org.elasticsearch.search.rank.rerank;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.search.rescore;
Add retrievers using the parser-only approach (#105470) This enhancement adds a new abstraction to the _search API called "retriever." A retriever is something that returns top hits. This adds three initial retrievers called "standard", "knn", and "rrf". The retrievers use a parser-only approach where they are parsed and then translated into a SearchSourceBuilder to execute the actual search. --------- Co-authored-by: Mayya Sharipova <mayya.sharipova@elastic.co>
2024-03-13 01:11:55 +08:00
exports org.elasticsearch.search.retriever;
Adding RankDocsRetrieverBuilder and RankDocsQuery (#111709)
2024-08-26 20:18:47 +08:00
exports org.elasticsearch.search.retriever.rankdoc;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.search.runtime;
exports org.elasticsearch.search.searchafter;
exports org.elasticsearch.search.slice;
exports org.elasticsearch.search.sort;
exports org.elasticsearch.search.suggest;
exports org.elasticsearch.search.suggest.completion;
exports org.elasticsearch.search.suggest.completion.context;
exports org.elasticsearch.search.suggest.phrase;
exports org.elasticsearch.search.suggest.term;
Move kNN search and dense vectors to core (#87815) This PR moves kNN search and dense vector support out of an xpack plugin and into server. In #87625 we plan to integrate ANN search into the main `_search` endpoint as a new top-level component called `knn`. So kNN will be a dedicated part of the search request, and we'll have kNN logic within the search phases. The classes and logic will live in server, matching the other search components like suggesters, field collapsing, etc.
2022-06-23 12:10:20 +08:00
exports org.elasticsearch.search.vectors;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.shutdown;
exports org.elasticsearch.snapshots;
Synonym Mgmnt API: PUT request (#95895)
2023-05-31 16:48:56 +08:00
exports org.elasticsearch.synonyms;
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
exports org.elasticsearch.tasks;
exports org.elasticsearch.threadpool;
exports org.elasticsearch.transport;
exports org.elasticsearch.upgrades;
exports org.elasticsearch.usage;
exports org.elasticsearch.watcher;
opens org.elasticsearch.common.logging to org.apache.logging.log4j.core;
Data stream lifecycle class names (#97381)
2023-07-05 17:28:32 +08:00
exports org.elasticsearch.action.datastreams.lifecycle;
Add service for computing the optimal number of shards for data streams (#105498) This adds the `DataStreamAutoShardingService` that will compute the optimal number of shards for a data stream and return a recommendation as to when to apply it (a time interval we call cool down which is 0 when the auto sharding recommendation can be applied immediately). This also introduces a `DataStreamAutoShardingEvent` object that will be stored in the data stream metadata to indicate the last auto sharding event that was applied to a data stream and its cluster state representation looks like so: ``` "auto_sharding": { "trigger_index_name": ".ds-logs-nginx-2024.02.12-000002", "target_number_of_shards": 3, "event_timestamp": 1707739707954 } ``` The auto sharding service is not used in this PR, so the auto sharding event will not be stored in the data stream metadata, but the required infrastructure to configure it is in place.
2024-03-06 18:12:08 +08:00
exports org.elasticsearch.action.datastreams.autosharding;
Introduce downsampling configuration for data stream lifecycle (#97041) This PR introduces downsampling configuration to the data stream lifecycle. Keep in mind downsampling implementation will come in a follow up PR. Configuration looks like this: ``` { "lifecycle": { "data_retention": "90d", "downsampling": [ { "after": "1d", "fixed_interval": "2h" }, { "after": "15d", "fixed_interval": "1d" }, { "after": "30d", "fixed_interval": "1w" } ] } } ``` We will also support using `null` to unset downsampling configuration during template composition: ``` { "lifecycle": { "data_retention": "90d", "downsampling": null } } ```
2023-06-29 21:41:17 +08:00
exports org.elasticsearch.action.downsample;
Add settings registration for Java modules through SPI (#98857) Currently plugins register settings through Plugin.getSettings. For easier breakdown of the codebase, it would be nice to allow arbitrary Java modules to register settings. This commit adds an internal SettingsExtension SPI which acts just like Plugin.getSettings but from a purely static context.
2023-08-25 22:00:49 +08:00
exports org.elasticsearch.plugins.internal
to
org.elasticsearch.metering,
Refactor reporting of RA metrics to not to be done in TransportShardBulkAction (#108449) previously DocumentSizeReporter was reporting upon indexing being completed in TransportShardBulkAction#onComplete This commit renames the method to onIndexingCompleted and moves that reporting to IndexEngine in serverless plugin. This will be followed up in a separate PR that will be reporting in an Engine#index subclass (serverless)
2024-05-16 19:57:06 +08:00
org.elasticsearch.stateless,
Add settings registration for Java modules through SPI (#98857) Currently plugins register settings through Plugin.getSettings. For easier breakdown of the codebase, it would be nice to allow arbitrary Java modules to register settings. This commit adds an internal SettingsExtension SPI which acts just like Plugin.getSettings but from a purely static context.
2023-08-25 22:00:49 +08:00
org.elasticsearch.settings.secure,
Make cat actions list extensible (#99504) This commit adds an internal extension for controlling which cat actions are returned by /_cat.
2023-09-14 11:48:09 +08:00
org.elasticsearch.serverless.constants,
Extensible Completion Postings Formats (#111494) Allows the Completion Postings Format to be extensible by providing an implementation of the CompletionsPostingsFormatExtension SPIs.
2024-11-29 05:25:02 +08:00
org.elasticsearch.serverless.codec,
Allow additional JSON log fields via SPI (#106980) This adds a new SPI based `LoggingDataProvider` service that can be implemented in order to add new fields to the main JSON log
2024-04-11 10:14:00 +08:00
org.elasticsearch.serverless.apifiltering,
org.elasticsearch.internal.security;
Rename tracing to telemetry package (#99710) This commit renames the tracing to telemetry.tracing in both xpack/APM and elasticserach's org.elasticsearch.tracing.Tracer (the api) the xpack/APM is renamed as follows: org.elasticsearch.telemetry.apm - the only exported package org.elasticsearch.telemetry.apm.settings - APMSettings org.elasticsearch.telemetry.apm.tracing - APMTracer org.elasticsearch.tracing.Tracer is moved to org.elasticsearch.telemetry.tracing.Tracer (responsible for majority of the changes in this PR)
2023-09-20 22:58:02 +08:00
exports org.elasticsearch.telemetry.tracing;
Rename TracerPlugin to TelemetryPlugin (#99735) with the support of metrics the TracerPlugin name is no longer adequate. Renaming this to TelemetryPlugin. Also introducing TelemetryProvider interface. While it is only used in Node.java at the moment to fetch Tracer instance, it is intended to be used in Plugin::createComponents (to be done in separate commit due to the broad scope of this method) This will allow for plugins to get access to both Tracer and Metric interfaces without the need to add yet another argument to createComponents Also adding internal subpackage in module/apm so that it is more obvious which packages are not exported
2023-09-22 19:35:36 +08:00
exports org.elasticsearch.telemetry;
APM Metering API (#99832) Adds Metering instrument interfaces and adapter implementations for opentelemetry instrument types: * Gauge - a single number that can go up or down * Histogram - bucketed samples * Counter - monotonically increasing summed value * UpDownCounter - summed value that may decrease Supports both Long* and Double* versions of the instruments. Instruments can be registered and retrieved by name through APMMeter which is available via the APMTelemetryProvider. The metering provider starts as the open telemetry noop provider. `telemetry.metrics.enabled` turns on metering.
2023-09-29 08:35:46 +08:00
exports org.elasticsearch.telemetry.metric;
Introduce a _lifecycle/explain API for data stream backing indices (#94621) This adds an {index}/_lifecycle/explain API to retrieve information about an index's status within its lifecycle. The response looks like so: ``` "indices" : { ".ds-metrics-foo-2023.03.22-000001" : { "index" : ".ds-metrics-foo-2023.03.22-000001", "managed_by_dlm" : true, "index_creation_date_millis" : 1679475563571, "time_since_index_creation" : "843ms", "rollover_date_millis" : 1679475564293, "time_since_rollover" : "121ms", "lifecycle" : { }, "generation_time" : "121ms" }, ".ds-metrics-foo-2023.03.22-000002" : { "index" : ".ds-metrics-foo-2023.03.22-000002", "managed_by_dlm" : true, "index_creation_date_millis" : 1679475564351, "time_since_index_creation" : "63ms", "lifecycle" : { } } } } ```
2023-03-27 15:44:40 +08:00
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
provides org.elasticsearch.xcontent.ErrorOnUnknown with org.elasticsearch.common.xcontent.SuggestingErrorOnUnknown;
provides org.elasticsearch.xcontent.XContentBuilderExtension with org.elasticsearch.common.xcontent.XContentElasticsearchExtension;
provides org.elasticsearch.cli.CliToolProvider
with
org.elasticsearch.cluster.coordination.NodeToolCliProvider,
org.elasticsearch.index.shard.ShardToolCliProvider;
Implement ILM/settings operator handlers (#88097) Relates to #86224
2022-07-05 00:12:49 +08:00
Rename immutable cluster state to reserved cluster state (#88481)
2022-07-14 03:05:39 +08:00
uses org.elasticsearch.reservedstate.ReservedClusterStateHandlerProvider;
Move preallocate module to libs (#94884) The preallocate module needs access to java.io internals. However, in order to open java.io to a specific module, rather than the unnamed module as was previously done, the said module must be in the boot layer. This commit moves the preallocate module to libs. It adds it to the main lib dir, though it does not add it as a compile dependency of server.
2023-04-11 04:05:43 +08:00
uses org.elasticsearch.jdk.ModuleQualifiedExportsService;
Add mechanism to react to termination signals (#95850) This commit adds a mechanism to be exposed internally to allow plugins/modules to react to termination signals via SPI. I'm not entirely sure how to test this - normally I'd use an `ESIntegTestCase` and supply a stubbed version of the plugin but that's more difficult with SPI. Supercedes https://github.com/elastic/elasticsearch/pull/95518
2023-05-18 05:18:37 +08:00
uses org.elasticsearch.node.internal.TerminationHandlerProvider;
Make current Version pluggable for serverless (#96539) Version.CURRENT is statically loaded as a constant early during startup. Yet serverless needs to be able to override the current Version so it can add additional versions. This commit makes Version.CURRENT pluggable via SPI. Note that the only way for this to be plugged in is via an additional jar on the boot layer.
2023-06-06 23:32:01 +08:00
uses org.elasticsearch.internal.VersionExtension;
Make build info pluggable internally (#97768) This commit makes the Build.current() pluggable. This is only available for internal builds.
2023-07-19 21:02:57 +08:00
uses org.elasticsearch.internal.BuildExtension;
Extensible Completion Postings Formats (#111494) Allows the Completion Postings Format to be extensible by providing an implementation of the CompletionsPostingsFormatExtension SPIs.
2024-11-29 05:25:02 +08:00
uses CompletionsPostingsFormatExtension;
Create new feature API for querying features present on a cluster (#100974) This adds an internal API and service to manage & get information on features that are present on nodes in a cluster. New features can be declared as supported, and historical features can be added to previous node versions to eventually replace node version comparisons
2023-10-30 22:38:30 +08:00
uses org.elasticsearch.features.FeatureSpecification;
Allow additional JSON log fields via SPI (#106980) This adds a new SPI based `LoggingDataProvider` service that can be implemented in order to add new fields to the main JSON log
2024-04-11 10:14:00 +08:00
uses org.elasticsearch.plugins.internal.LoggingDataProvider;
Create new feature API for querying features present on a cluster (#100974) This adds an internal API and service to manage & get information on features that are present on nodes in a cluster. New features can be declared as supported, and historical features can be added to previous node versions to eventually replace node version comparisons
2023-10-30 22:38:30 +08:00
Add historical feature for cluster health checks (#101538)
2023-10-31 18:06:14 +08:00
provides org.elasticsearch.features.FeatureSpecification
with
Index stats enhancement: creation date and tier_preference (#116339) * Expose tier preference as part of the index stats * Also expose index creation date in index stats * Added test
2024-11-15 16:08:42 +08:00
org.elasticsearch.action.admin.indices.stats.IndicesStatsFeatures,
Adding mapping validation to the simulate ingest API (#110606)
2024-07-19 21:08:21 +08:00
org.elasticsearch.action.bulk.BulkFeatures,
Unify naming of feature spec implementations (#101704) Use a naming scheme of <area>Features
2023-11-03 17:24:50 +08:00
org.elasticsearch.features.FeatureInfrastructureFeatures,
org.elasticsearch.health.HealthFeatures,
Migrate desirednode processors version checks to features (#101706)
2023-11-03 21:57:47 +08:00
org.elasticsearch.cluster.metadata.MetadataFeatures,
Add feature for index mapping auto-put (#101668)
2023-11-13 21:43:56 +08:00
org.elasticsearch.rest.RestFeatures,
Add telemetry for repository usage (#112133) Adds to the `GET _cluster/stats` endpoint information about the snapshot repositories in use, including their types, whether they are read-only or read-write, and for Azure repositories the kind of credentials in use.
2024-08-27 21:34:02 +08:00
org.elasticsearch.repositories.RepositoriesFeatures,
Support effective watermark thresholds in node stats API (#107244) Adds to the `fs` component of the node stats API some additional values indicating the disk watermarks that are currently in effect. Relates #106676
2024-04-18 21:57:28 +08:00
org.elasticsearch.action.admin.cluster.allocation.AllocationStatsFeatures,
Remove cluster state from `/_cluster/reroute` response (#114231) Including the cluster state in responses to the `POST _cluster/state` API was deprecated in #90399 (v8.6.0) requiring callers to pass `?metric=none` to avoid the deprecation warning. This commit adjusts the behaviour as promised in v9 so that this API never returns the cluster state, and deprecates the `?metric` parameter itself. Closes #88978
2024-10-08 14:59:57 +08:00
org.elasticsearch.rest.action.admin.cluster.ClusterRerouteFeatures,
Add ignored field values to synthetic source (#107567) * Add ignored field values to synthetic source * Update docs/changelog/107567.yaml * initialize map * yaml fix * add node feature * add comments * small fixes * missing cluster feature in yaml * constants for chars, stored fields * remove duplicate method * throw exception on parse failure * remove Base64 encoding * add assert on IgnoredValuesFieldMapper::write * changes from review * simplify logic * add comment * rename classes * rename _ignored_values to _ignored_source * rename _ignored_values to _ignored_source
2024-04-26 20:35:31 +08:00
org.elasticsearch.index.mapper.MapperFeatures,
Directly download commercial ip geolocation databases from providers (#110844) Co-authored-by: Keith Massey <keith.massey@elastic.co>
2024-07-18 08:55:14 +08:00
org.elasticsearch.ingest.IngestGeoIpFeatures,
Support k parameter for knn query (#110233) Introduce an optional k param for knn query If k is not set, knn query has the previous behaviour: - `num_candidates` docs is collected from each shard. This `num_candidates` docs are used for combining with results with other queries and aggregations on each shard. - docs from all shards are merged to produce the top global `size` results If k is set, the behaviour instead is following: - `k` docs is collected from each shard. This `k` docs are used for combining results with other queries and aggregations on each shard. - similarly, docs from all shards are merged to produce the top global `size` results. Having `k` param makes it more intuitive for users to address their needs. They also don't need to care and can skip `num_candidates` param for this query as it is of more internal details to tune how knn search operates. Closes #108473
2024-06-28 21:59:28 +08:00
org.elasticsearch.search.SearchFeatures,
Adding hamming distance function to painless for dense_vector fields (#109359) This adds `hamming` distances, the pop-count of `xor` byte vectors as a first class citizen in painless. For byte vectors, this means that we can compute hamming distances via script_score (aka, brute-force). The implementation of `hamming` is the same that is available in Lucene, and when lucene 9.11 is merged, we should update our logic where applicable to utilize it. NOTE: this does not yet add hamming distance as a metric for indexed vectors. This will be a future PR after the Lucene 9.11 upgrade.
2024-06-18 01:41:20 +08:00
org.elasticsearch.script.ScriptFeatures,
Guard file settings readiness on file settings support (#109500) Consistency of file settings is an important invariant. However, when upgrading from Elasticsearch versions before file settings existed, cluster state will not yet have the file settings metadata. If the first node upgraded is not the master node, new nodes will never become ready while they wait for file settings metadata to exist. This commit adds a node feature for file settings to guard waiting on file settings for readiness. Although file settings has existed since 8.4, the feature is not a historical feature because historical features are not applied to cluster state that readiness checks. In this case it is not needed since upgrading from 8.4+ will already contain file settings metadata.
2024-06-11 04:55:53 +08:00
org.elasticsearch.search.retriever.RetrieversFeatures,
Add source mode stats to MappingStats (#117463)
2024-11-28 17:53:39 +08:00
org.elasticsearch.reservedstate.service.FileSettingsFeatures,
org.elasticsearch.action.admin.cluster.stats.ClusterStatsFeatures;
Create new feature API for querying features present on a cluster (#100974) This adds an internal API and service to manage & get information on features that are present on nodes in a cluster. New features can be declared as supported, and historical features can be added to previous node versions to eventually replace node version comparisons
2023-10-30 22:38:30 +08:00
Add settings registration for Java modules through SPI (#98857) Currently plugins register settings through Plugin.getSettings. For easier breakdown of the codebase, it would be nice to allow arbitrary Java modules to register settings. This commit adds an internal SettingsExtension SPI which acts just like Plugin.getSettings but from a purely static context.
2023-08-25 22:00:49 +08:00
uses org.elasticsearch.plugins.internal.SettingsExtension;
Make cat actions list extensible (#99504) This commit adds an internal extension for controlling which cat actions are returned by /_cat.
2023-09-14 11:48:09 +08:00
uses RestExtension;
Add component info versions to node info in a pluggable way (#99631) This adds a `ComponentVersionNumber` service interface for modules to provide version numbers for individual components to be reported inside node info. Initial implementations for `MlConfigVersion` and `TransformConfigVersion` are provided.
2023-09-22 00:08:43 +08:00
uses org.elasticsearch.action.admin.cluster.node.info.ComponentVersionNumber;
Enable BloomFilter for _id of non-datastream indices (#88409) This PR adds BloomFilter to Elasticsearch and enables it for the _id field of non-data stream indices. BloomFilter should speed up the performance of mget and update requests at a small expense of refresh, merge, and storage.
2022-08-08 23:14:26 +08:00
Improve the false positive rate of the bloom filter by setting 7 hash functions (#93283) Co-authored-by: Adrien Grand <jpountz@gmail.com>
2023-02-04 20:42:26 +08:00
provides org.apache.lucene.codecs.PostingsFormat
with
org.elasticsearch.index.codec.bloomfilter.ES85BloomFilterPostingsFormat,
Introduce Elasticsearch PostingFormat based on Lucene 90 positing format using PFOR (#103601) Lucene 9.9 has introduced a new posting format that uses FOR instead of PFOR. Elasticsearch prefers the former format, therefore we introduce it as a our own posting format here.
2023-12-20 22:09:24 +08:00
org.elasticsearch.index.codec.bloomfilter.ES87BloomFilterPostingsFormat,
org.elasticsearch.index.codec.postings.ES812PostingsFormat;
Adding new bbq index types behind a feature flag (#114439) new index types of bbq_hnsw and bbq_flat which utilize the better binary quantization formats. A 32x reduction in memory, with nice recall properties.
2024-10-15 08:13:27 +08:00
provides org.apache.lucene.codecs.DocValuesFormat with org.elasticsearch.index.codec.tsdb.ES87TSDBDocValuesFormat;
Add new int8_flat and flat vector index types (#104872) This adds two new vector index types: - flat - int8_flat Both store the vectors in a flat space and search is brute-force over the vectors in the index. For the regular `flat` index, this can be considered syntactic sugar that allows `knn` queries without having to put indices within HNSW. For `int8_flat`, this allows float vectors to be stored in a flat manner, but also automatically quantized.
2024-02-06 01:56:13 +08:00
provides org.apache.lucene.codecs.KnnVectorsFormat
with
org.elasticsearch.index.codec.vectors.ES813FlatVectorFormat,
Add an optimised int8 vector distance function for aarch64. (#106133) This commit adds an optimised int8 vector distance implementation for aarch64. Additional platforms like, say, x64, will be added as a follow-up. The vector distance implementation outperforms Lucene's Pamana Vector implementation for binary comparisons by approx 5x (depending on the number of dimensions). It does so by means of compiler intrinsics built into a separate native library and link by Panama's FFI. Comparisons are performed on off-heap mmap'ed vector data. The implementation is currently only used during merging of scalar quantized segments, through a custom format ES814HnswScalarQuantizedVectorsFormat, but its usage will likely be expanded over time. Co-authored-by: Benjamin Trent <ben.w.trent@gmail.com> Co-authored-by: Lorenzo Dematté <lorenzo.dematte@elastic.co> Co-authored-by: Mark Vieira <portugee@gmail.com> Co-authored-by: Ryan Ernst <ryan@iernst.net>
2024-04-12 15:44:21 +08:00
org.elasticsearch.index.codec.vectors.ES813Int8FlatVectorFormat,
Adds new `bit` element_type for dense_vectors (#110059) This commit adds `bit` vector support by adding `element_type: bit` for vectors. This new element type works for indexed and non-indexed vectors. Additionally, it works with `hnsw` and `flat` index types. No quantization based codec works with this element type, this is consistent with `byte` vectors. `bit` vectors accept up to `32768` dimensions in size and expect vectors that are being indexed to be encoded either as a hexidecimal string or a `byte[]` array where each element of the `byte` array represents `8` bits of the vector. `bit` vectors support script usage and regular query usage. When indexed, all comparisons done are `xor` and `popcount` summations (aka, hamming distance), and the scores are transformed and normalized given the vector dimensions. Note, indexed bit vectors require `l2_norm` to be the similarity. For scripts, `l1norm` is the same as `hamming` distance and `l2norm` is `sqrt(l1norm)`. `dotProduct` and `cosineSimilarity` are not supported. Note, the dimensions expected by this element_type are always to be divisible by `8`, and the `byte[]` vectors provided for index must be have size `dim/8` size, where each byte element represents `8` bits of the vectors. closes: https://github.com/elastic/elasticsearch/issues/48322
2024-06-27 02:48:41 +08:00
org.elasticsearch.index.codec.vectors.ES814HnswScalarQuantizedVectorsFormat,
org.elasticsearch.index.codec.vectors.ES815HnswBitVectorsFormat,
Adding new bbq index types behind a feature flag (#114439) new index types of bbq_hnsw and bbq_flat which utilize the better binary quantization formats. A 32x reduction in memory, with nice recall properties.
2024-10-15 08:13:27 +08:00
org.elasticsearch.index.codec.vectors.ES815BitFlatVectorFormat,
Refactor/bbq format (#117847) * Refactor bbq format to be contained in a package * fixing license headers * fixing module * fix style
2024-12-03 05:04:31 +08:00
org.elasticsearch.index.codec.vectors.es816.ES816BinaryQuantizedVectorsFormat,
org.elasticsearch.index.codec.vectors.es816.ES816HnswBinaryQuantizedVectorsFormat;
Adds new `bit` element_type for dense_vectors (#110059) This commit adds `bit` vector support by adding `element_type: bit` for vectors. This new element type works for indexed and non-indexed vectors. Additionally, it works with `hnsw` and `flat` index types. No quantization based codec works with this element type, this is consistent with `byte` vectors. `bit` vectors accept up to `32768` dimensions in size and expect vectors that are being indexed to be encoded either as a hexidecimal string or a `byte[]` array where each element of the `byte` array represents `8` bits of the vector. `bit` vectors support script usage and regular query usage. When indexed, all comparisons done are `xor` and `popcount` summations (aka, hamming distance), and the scores are transformed and normalized given the vector dimensions. Note, indexed bit vectors require `l2_norm` to be the similarity. For scripts, `l1norm` is the same as `hamming` distance and `l2norm` is `sqrt(l1norm)`. `dotProduct` and `cosineSimilarity` are not supported. Note, the dimensions expected by this element_type are always to be divisible by `8`, and the `byte[]` vectors provided for index must be have size `dim/8` size, where each byte element represents `8` bits of the vectors. closes: https://github.com/elastic/elasticsearch/issues/48322
2024-06-27 02:48:41 +08:00
Upgrade to Lucene 9.12.0 (#113333) This commit upgrades to Lucene 9.12.0. Co-authored-by: Adrien Grand <jpountz@gmail.com> Co-authored-by: Armin Braun <me@obrown.io> Co-authored-by: Benjamin Trent <ben.w.trent@gmail.com> Co-authored-by: Chris Hegarty <chegar999@gmail.com> Co-authored-by: John Wagster <john.wagster@elastic.co> Co-authored-by: Luca Cavanna <javanna@apache.org> Co-authored-by: Mayya Sharipova <mayya.sharipova@elastic.co>
2024-10-01 15:39:27 +08:00
provides org.apache.lucene.codecs.Codec
with
org.elasticsearch.index.codec.Elasticsearch814Codec,
Upgrade to Lucene 10 (#114741) The most relevant ES changes that upgrading to Lucene 10 requires are: - use the appropriate IOContext - Scorer / ScorerSupplier breaking changes - Regex automaton are no longer determinized by default - minimize moved to test classes - introduce Elasticsearch900Codec - adjust slicing code according to the added support for intra-segment concurrency - disable intra-segment concurrency in tests - adjust accessor methods for many Lucene classes that became a record - adapt to breaking changes in the analysis area Co-authored-by: Christoph Büscher <christophbuescher@posteo.de> Co-authored-by: Mayya Sharipova <mayya.sharipova@elastic.co> Co-authored-by: ChrisHegarty <chegar999@gmail.com> Co-authored-by: Brian Seeders <brian.seeders@elastic.co> Co-authored-by: Armin Braun <me@obrown.io> Co-authored-by: Panagiotis Bailis <pmpailis@gmail.com> Co-authored-by: Benjamin Trent <4357155+benwtrent@users.noreply.github.com>
2024-10-21 19:38:23 +08:00
org.elasticsearch.index.codec.Elasticsearch816Codec,
org.elasticsearch.index.codec.Elasticsearch900Codec;
Modularize shard availability service (#101796) * Modularize shard availability service This commit moves the `ShardsAvailabilityHealthIndicatorService` to a package and modularizes it with exports so that Serverless can make use of it as a superclass. Relates to #101394
2023-11-04 05:59:09 +08:00
Allow additional JSON log fields via SPI (#106980) This adds a new SPI based `LoggingDataProvider` service that can be implemented in order to add new fields to the main JSON log
2024-04-11 10:14:00 +08:00
provides org.apache.logging.log4j.core.util.ContextDataProvider with org.elasticsearch.common.logging.DynamicContextDataProvider;
[Health API] Abstract data tier diagnoses as node roles (#102466) We generalise the code that is diagnosing the shard availability when it comes to data tier issues. We make it more extensible, so in serverless we can introduce new roles. For this reason, we consider a tier as a more specific kind of a role. Then we expose some methods and some diagnosis definitions in the ShardsAvailabilityHealthIndicatorService so they can be extended.
2023-11-22 23:20:10 +08:00
exports org.elasticsearch.cluster.routing.allocation.shards
to
org.elasticsearch.shardhealth,
org.elasticsearch.serverless.shardhealth,
org.elasticsearch.serverless.apifiltering;
Move doc-values classes needed by ST_INTERSECTS to server (#104980) * Move doc-values classes needed by ST_INTERSECTS to server This classes are needed by ESQL spatial queries, and are not licensed in a way that prevents this move. Since they depend on lucene it is not possible to move them to a library. Instead they are moved to be co-located with the GeoPoint doc-values classes that already exist in server. * Moved to lucene package org.elasticsearch.lucene.spatial * Moved Geo/ShapeDocValuesQuery to server because it is Lucene specific And this gives us access to these classes from ESQL for lucene-pushdown of spatial queries.
2024-02-07 22:00:38 +08:00
exports org.elasticsearch.lucene.spatial;
[Inference API] Add API to get configuration of inference services (#114862) * Adding API to get list of service configurations * Update docs/changelog/114862.yaml * Fixing some configurations * PR feedback -> Stream.of * PR feedback -> singleton * Renaming ServiceConfiguration to SettingsConfiguration. Adding TaskSettingsConfiguration * Adding task type settings configuration to response * PR feedback
2024-10-31 01:29:58 +08:00
exports org.elasticsearch.inference.configuration;
Add num docs and size to logsdb telemetry (#116128) Follow-up on #115994 to add telemetry for the total number of documents and size in bytes of logsdb indices. Relates #115994
2024-11-06 00:46:46 +08:00
exports org.elasticsearch.monitor.metrics;
Directly download commercial ip geolocation databases from providers (#110844) Co-authored-by: Keith Massey <keith.massey@elastic.co>
2024-07-18 08:55:14 +08:00
Modularize Elasticsearch (#81066) This PR represents the initial phase of Modularizing Elasticsearch (with Java Modules). This initial phase modularizes the core of the Elasticsearch server with Java Modules, which is then used to load and configure extension components atop the server. Only a subset of extension components are modularized at this stage (other components come in a later phase). Components are loaded dynamically at runtime with custom class loaders (same as is currently done). Components with a module-info.class are defined to a module layer. This architecture is somewhat akin to the Modular JDK, where applications run on the classpath. In the analogy, the Elasticsearch server modules are the platform (thus are always resolved and present), while components without a module-info.class are non-modular code running atop the Elasticsearch server modules. The extension components cannot access types from non-exported packages of the server modules, in the same way that classpath applications cannot access types from non-exported packages of modules from the JDK. Broadly, the core Elasticseach java modules simply "wrap" the existing packages and export them. There are opportunites to export less, which is best done in more narrowly focused follow-up PRs. The Elasticsearch distribution startup scripts are updated to put jars on the module path (the class path is empty), so the distribution will run the core of the server as java modules. A number of key components have been retrofitted with module-info.java's too, and the remaining components can follow later. Unit and functional tests run as non-modular (since they commonly require package-private access), while higher-level integration tests, that run the distribution, run as modular. Co-authored-by: Chris Hegarty <christopher.hegarty@elastic.co> Co-authored-by: Ryan Ernst <ryan@iernst.net> Co-authored-by: Rene Groeschke <rene@elastic.co>
2022-05-20 20:11:42 +08:00
}