Quarkus - Hibernate Search guide

You have a Hibernate ORM-based application? You want to provide a full-featured full-text search to your users? You’re at the right place.

With this guide, you’ll learn how to synchronize your entities to an Elasticsearch cluster in a heart beat with Hibernate Search. We will also explore how you can can query your Elasticsearch cluster using the Hibernate Search API.

Prerequisites

To complete this guide, you need:

Architecture

The application described in this guide allows to manage a (simple) library: you manage authors and their books.

The entities are stored in a PostgreSQL database and indexed in an Elasticsearch cluster.

Solution

We recommend that you follow the instructions in the next sections and create the application step by step. However, you can go right to the completed example.

Clone the Git repository: git clone https://github.com/quarkusio/quarkus-quickstarts.git, or download an archive.

The solution is located in the hibernate-search-orm-elasticsearch-quickstart directory.

The provided solution contains a few additional elements such as tests and testing infrastructure.

Creating the Maven project

First, we need a new project. Create a new project with the following command:

mvn io.quarkus:quarkus-maven-plugin:1.13.4.Final:create \
    -DprojectGroupId=org.acme \
    -DprojectArtifactId=hibernate-search-orm-elasticsearch-quickstart \
    -DclassName="org.acme.hibernate.search.elasticsearch.LibraryResource" \
    -Dpath="/library" \
    -Dextensions="resteasy,hibernate-orm-panache,hibernate-search-orm-elasticsearch,resteasy-jackson,jdbc-postgresql"
cd hibernate-search-orm-elasticsearch-quickstart

This command generates a Maven structure importing the following extensions:

  • Hibernate ORM with Panache,

  • the PostgreSQL JDBC driver,

  • Hibernate Search + Elasticsearch,

  • RESTEasy and Jackson.

If you already have your Quarkus project configured, you can add the hibernate-search-orm-elasticsearch extension to your project by running the following command in your project base directory:

./mvnw quarkus:add-extension -Dextensions="hibernate-search-orm-elasticsearch"

This will add the following to your pom.xml:

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-hibernate-search-orm-elasticsearch</artifactId>
</dependency>

For now, let’s delete the two generated tests LibraryResourceTest and NativeLibraryResourceIT present in src/test/java. If you are interested in how you can test this application, just refer to the solution in the quickstarts Git repository: it contains a lot of tests and the required testing infrastructure.

Creating the bare entities

First, let’s create our Hibernate ORM entities Book and Author in the model subpackage.

package org.acme.hibernate.search.elasticsearch.model;

import java.util.List;
import java.util.Objects;

import javax.persistence.CascadeType;
import javax.persistence.Entity;
import javax.persistence.FetchType;
import javax.persistence.OneToMany;

import io.quarkus.hibernate.orm.panache.PanacheEntity;

@Entity
public class Author extends PanacheEntity { (1)

    public String firstName;

    public String lastName;

    @OneToMany(mappedBy = "author", cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.EAGER) (2)
    public List<Book> books;

    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (!(o instanceof Author)) {
            return false;
        }

        Author other = (Author) o;

        return Objects.equals(id, other.id);
    }

    @Override
    public int hashCode() {
        return 31;
    }
}
1 We are using Hibernate ORM with Panache, it is not mandatory.
2 We are loading these elements eagerly so that they are present in the JSON output. In a real world application, you should probably use a DTO approach.
package org.acme.hibernate.search.elasticsearch.model;

import java.util.Objects;

import javax.persistence.Entity;
import javax.persistence.ManyToOne;

import com.fasterxml.jackson.annotation.JsonIgnore;

import io.quarkus.hibernate.orm.panache.PanacheEntity;

@Entity
public class Book extends PanacheEntity {

    public String title;

    @ManyToOne
    @JsonIgnore (1)
    public Author author;

    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (!(o instanceof Book)) {
            return false;
        }

        Book other = (Book) o;

        return Objects.equals(id, other.id);
    }

    @Override
    public int hashCode() {
        return 31;
    }
}
1 We mark this property with @JsonIgnore to avoid infinite loops when serializing with Jackson.

Initializing the REST service

While everything is not yet set up for our REST service, we can initialize it with the standard CRUD operations we will need.

Just copy this content in the LibraryResource file created by the Maven create-project command:

package org.acme.hibernate.search.elasticsearch;

import javax.transaction.Transactional;
import javax.ws.rs.Consumes;
import javax.ws.rs.DELETE;
import javax.ws.rs.POST;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

import org.acme.hibernate.search.elasticsearch.model.Author;
import org.acme.hibernate.search.elasticsearch.model.Book;
import org.jboss.resteasy.annotations.jaxrs.FormParam;
import org.jboss.resteasy.annotations.jaxrs.PathParam;

@Path("/library")
public class LibraryResource {

    @PUT
    @Path("book")
    @Transactional
    @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
    public void addBook(@FormParam String title, @FormParam Long authorId) {
        Author author = Author.findById(authorId);
        if (author == null) {
            return;
        }

        Book book = new Book();
        book.title = title;
        book.author = author;
        book.persist();

        author.books.add(book);
        author.persist();
    }

    @DELETE
    @Path("book/{id}")
    @Transactional
    public void deleteBook(@PathParam Long id) {
        Book book = Book.findById(id);
        if (book != null) {
            book.author.books.remove(book);
            book.delete();
        }
    }

    @PUT
    @Path("author")
    @Transactional
    @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
    public void addAuthor(@FormParam String firstName, @FormParam String lastName) {
        Author author = new Author();
        author.firstName = firstName;
        author.lastName = lastName;
        author.persist();
    }

    @POST
    @Path("author/{id}")
    @Transactional
    @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
    public void updateAuthor(@PathParam Long id, @FormParam String firstName, @FormParam String lastName) {
        Author author = Author.findById(id);
        if (author == null) {
            return;
        }
        author.firstName = firstName;
        author.lastName = lastName;
        author.persist();
    }

    @DELETE
    @Path("author/{id}")
    @Transactional
    public void deleteAuthor(@PathParam Long id) {
        Author author = Author.findById(id);
        if (author != null) {
            author.delete();
        }
    }
}

Nothing out of the ordinary here: it is just good old Hibernate ORM with Panache operations in a standard JAX-RS service.

In fact, the interesting part is that we will need to add very few elements to make our full text search application working.

Using Hibernate Search annotations

Let’s go back to our entities.

Enabling full text search capabilities for them is as simple as adding a few annotations.

Let’s edit the Book entity again to include this content:

package org.acme.hibernate.search.elasticsearch.model;

import java.util.Objects;

import javax.persistence.Entity;
import javax.persistence.ManyToOne;

import org.hibernate.search.mapper.pojo.mapping.definition.annotation.FullTextField;
import org.hibernate.search.mapper.pojo.mapping.definition.annotation.Indexed;

import com.fasterxml.jackson.annotation.JsonIgnore;

import io.quarkus.hibernate.orm.panache.PanacheEntity;

@Entity
@Indexed (1)
public class Book extends PanacheEntity {

    @FullTextField(analyzer = "english") (2)
    public String title;

    @ManyToOne
    @JsonIgnore
    public Author author;

    // Preexisting equals()/hashCode() methods
}
1 First, let’s use the @Indexed annotation to register our Book entity as part of the full text index.
2 The @FullTextField annotation declares a field in the index specifically tailored for full text search. In particular, we have to define an analyzer to split and analyze the tokens (~ words) - more on this later.

Now that our books are indexed, we can do the same for the authors.

Open the Author class and include the content below.

Things are quite similar here: we use the @Indexed, @FullTextField and @KeywordField annotations.

There are a few differences/additions though. Let’s check them out.

package org.acme.hibernate.search.elasticsearch.model;

import java.util.List;
import java.util.Objects;

import javax.persistence.CascadeType;
import javax.persistence.Entity;
import javax.persistence.FetchType;
import javax.persistence.OneToMany;

import org.hibernate.search.engine.backend.types.Sortable;
import org.hibernate.search.mapper.pojo.mapping.definition.annotation.FullTextField;
import org.hibernate.search.mapper.pojo.mapping.definition.annotation.Indexed;
import org.hibernate.search.mapper.pojo.mapping.definition.annotation.IndexedEmbedded;
import org.hibernate.search.mapper.pojo.mapping.definition.annotation.KeywordField;

import io.quarkus.hibernate.orm.panache.PanacheEntity;

@Entity
@Indexed
public class Author extends PanacheEntity {

    @FullTextField(analyzer = "name") (1)
    @KeywordField(name = "firstName_sort", sortable = Sortable.YES, normalizer = "sort") (2)
    public String firstName;

    @FullTextField(analyzer = "name")
    @KeywordField(name = "lastName_sort", sortable = Sortable.YES, normalizer = "sort")
    public String lastName;

    @OneToMany(mappedBy = "author", cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.EAGER)
    @IndexedEmbedded (3)
    public List<Book> books;

    // Preexisting equals()/hashCode() methods
}
1 We use a @FullTextField similar to what we did for Book but you’ll notice that the analyzer is different - more on this later.
2 As you can see, we can define several fields for the same property. Here, we define a @KeywordField with a specific name. The main difference is that a keyword field is not tokenized (the string is kept as one single token) but can be normalized (i.e. filtered) - more on this later. This field is marked as sortable as our intention is to use it for sorting our authors.
3 The purpose of @IndexedEmbedded is to include the Book fields into the Author index. In this case, we just use the default configuration: all the fields of the associated Book entities are included in the index (i.e. the title field). The nice thing with @IndexedEmbedded is that it is able to automatically reindex an Author if one of its Books has been updated thanks to the bidirectional relation. @IndexedEmbedded also supports nested documents (using the storage = NESTED attribute) but we don’t need it here. You can also specify the fields you want to include in your parent index using the includePaths attribute if you don’t want them all.

Analyzers and normalizers

Introduction

Analysis is a big part of full text search: it defines how text will be processed when indexing or building search queries.

The role of analyzers is to split the text into tokens (~ words) and filter them (making it all lowercase and removing accents for instance).

Normalizers are a special type of analyzers that keeps the input as a single token. It is especially useful for sorting or indexing keywords.

There are a lot of bundled analyzers but you can also develop your own for your own specific purposes.

You can learn more about the Elasticsearch analysis framework in the Analysis section of the Elasticsearch documentation.

Defining the analyzers used

When we added the Hibernate Search annotations to our entities, we defined the analyzers and normalizers used. Typically:

@FullTextField(analyzer = "english")
@FullTextField(analyzer = "name")
@KeywordField(name = "lastName_sort", sortable = Sortable.YES, normalizer = "sort")

We use:

  • an analyzer called name for person names,

  • an analyzer called english for book titles,

  • a normalizer called sort for our sort fields

but we haven’t set them up yet.

Let’s see how you can do it with Hibernate Search.

Setting up the analyzers

It is an easy task, we just need to create an implementation of ElasticsearchAnalysisConfigurer (and configure Quarkus to use it, more on that later).

To fulfill our requirements, let’s create the following implementation:

package org.acme.hibernate.search.elasticsearch.config;

import org.hibernate.search.backend.elasticsearch.analysis.ElasticsearchAnalysisConfigurationContext;
import org.hibernate.search.backend.elasticsearch.analysis.ElasticsearchAnalysisConfigurer;

import javax.enterprise.context.Dependent;
import javax.inject.Named;

@Dependent
@Named("myAnalysisConfigurer") (1)
public class AnalysisConfigurer implements ElasticsearchAnalysisConfigurer {

    @Override
    public void configure(ElasticsearchAnalysisConfigurationContext context) {
        context.analyzer("name").custom() (2)
                .tokenizer("standard")
                .tokenFilters("asciifolding", "lowercase");

        context.analyzer("english").custom() (3)
                .tokenizer("standard")
                .tokenFilters("asciifolding", "lowercase", "porter_stem");

        context.normalizer("sort").custom() (4)
                .tokenFilters("asciifolding", "lowercase");
    }
}
1 We will need to reference the configurer from the configuration properties, so we make it a named bean.
2 This is a simple analyzer separating the words on spaces, removing any non-ASCII characters by its ASCII counterpart (and thus removing accents) and putting everything in lowercase. It is used in our examples for the author’s names.
3 We are a bit more aggressive with this one and we include some stemming: we will be able to search for mystery and get a result even if the indexed input contains mysteries. It is definitely too aggressive for person names but it is perfect for the book titles.
4 Here is the normalizer used for sorting. Very similar to our first analyzer, except we don’t tokenize the words as we want one and only one token.

Adding full text capabilities to our REST service

In our existing LibraryResource, we just need to inject the SearchSession:

    @Inject
    SearchSession searchSession; (1)
1 Inject a Hibernate Search session, which relies on the EntityManager under the hood. Applications with multiple persistence units can use the CDI qualifier @io.quarkus.hibernate.orm.PersistenceUnit to select the right one: see CDI integration.

And then we can add the following methods (and a few imports):

    @Transactional (1)
    void onStart(@Observes StartupEvent ev) throws InterruptedException { (2)
        // only reindex if we imported some content
        if (Book.count() > 0) {
            searchSession.massIndexer()
                    .startAndWait();
        }
    }

    @GET
    @Path("author/search") (3)
    @Transactional
    public List<Author> searchAuthors(@QueryParam String pattern, (4)
            @QueryParam Optional<Integer> size) {
        return searchSession.search(Author.class) (5)
                .where(f ->
                    pattern == null || pattern.trim().isEmpty() ?
                            f.matchAll() : (6)
                            f.simpleQueryString()
                                .fields("firstName", "lastName", "books.title").matching(pattern) (7)
                )
                .sort(f -> f.field("lastName_sort").then().field("firstName_sort")) (8)
                .fetchHits(size.orElse(20)); (9)
    }
1 Important point: we need a transactional context for these methods.
2 As we will import data into the PostgreSQL database using an SQL script, we need to reindex the data at startup. For this, we use Hibernate Search’s mass indexer, which allows to index a lot of data efficiently (you can fine tune it for better performances). All the upcoming updates coming through Hibernate ORM operations will be synchronized automatically to the full text index. If you don’t import data manually in the database, you don’t need that: the mass indexer should then only be used when you change your indexing configuration (adding a new field, changing an analyzer’s configuration…​) and you want the new configuration to be applied to your existing entities.
3 This is where the magic begins: just adding the annotations to our entities makes them available for full text search: we can now query the index using the Hibernate Search DSL.
4 Use the org.jboss.resteasy.annotations.jaxrs.QueryParam annotation type to avoid repeating the parameter name.
5 We indicate that we are searching for Authors.
6 We create a predicate: if the pattern is empty, we use a matchAll() predicate.
7 If we have a valid pattern, we create a simpleQueryString() predicate on the firstName, lastName and books.title fields matching our pattern.
8 We define the sort order of our results. Here we sort by last name, then by first name. Note that we use the specific fields we created for sorting.
9 Fetch the size top hits, 20 by default. Obviously, paging is also supported.

The Hibernate Search DSL supports a significant subset of the Elasticsearch predicates (match, range, nested, phrase, spatial…​). Feel free to explore the DSL using autocompletion.

When that’s not enough, you can always fall back to defining a predicate using JSON directly.

Configuring the application

As usual, we can configure everything in the Quarkus configuration file, application.properties.

Edit src/main/resources/application.properties and inject the following configuration:

quarkus.ssl.native=false (1)

quarkus.datasource.db-kind=postgresql (2)
quarkus.datasource.username=quarkus_test
quarkus.datasource.password=quarkus_test
quarkus.datasource.jdbc.url=jdbc:postgresql:quarkus_test

quarkus.hibernate-orm.database.generation=drop-and-create (3)
quarkus.hibernate-orm.sql-load-script=import.sql (4)

quarkus.hibernate-search-orm.elasticsearch.version=7 (5)
quarkus.hibernate-search-orm.elasticsearch.analysis.configurer=bean:myAnalysisConfigurer (6)
quarkus.hibernate-search-orm.schema-management.strategy=drop-and-create (7)
quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy=sync (8)
1 We won’t use SSL so we disable it to have a more compact native executable.
2 Let’s create a PostgreSQL datasource.
3 We will drop and recreate the schema every time we start the application.
4 We load some initial data.
5 We need to tell Hibernate Search about the version of Elasticsearch we will use. It is important because there are significant differences between Elasticsearch mapping syntax depending on the version. Since the mapping is created at build time to reduce startup time, Hibernate Search cannot connect to the cluster to automatically detect the version.
6 We point to the custom AnalysisConfigurer which defines the configuration of our analyzers and normalizers.
7 Obviously, this is not for production: we drop and recreate the index every time we start the application.
8 This means that we wait for the entities to be searchable before considering a write complete. On a production setup, the write-sync default will provide better performance. Using sync is especially important when testing as you need the entities to be searchable immediately.
For more information about the Hibernate Search extension configuration please refer to the Configuration Reference.

Creating a frontend

Now let’s add a simple web page to interact with our LibraryResource. Quarkus automatically serves static resources located under the META-INF/resources directory. In the src/main/resources/META-INF/resources directory, overwrite the existing index.html file with the content from this index.html file.

Automatic import script

For the purpose of this demonstration, let’s import an initial dataset.

Let’s create a src/main/resources/import.sql file with the following content:

INSERT INTO author(id, firstname, lastname) VALUES (nextval('hibernate_sequence'), 'John', 'Irving');
INSERT INTO author(id, firstname, lastname) VALUES (nextval('hibernate_sequence'), 'Paul', 'Auster');

INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'The World According to Garp', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'The Hotel New Hampshire', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'The Cider House Rules', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'A Prayer for Owen Meany', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'Last Night in Twisted River', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'In One Person', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'Avenue of Mysteries', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'The New York Trilogy', 2);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'Mr. Vertigo', 2);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'The Brooklyn Follies', 2);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'Invisible', 2);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'Sunset Park', 2);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), '4 3 2 1', 2);

Preparing the infrastructure

We need a PostgreSQL instance and an Elasticsearch cluster.

Let’s use Docker to start one of each:

docker run -it --rm=true --name elasticsearch_quarkus_test -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch-oss:{elasticsearch-version}
docker run --ulimit memlock=-1:-1 -it --rm=true --memory-swappiness=0 --name postgresql_quarkus_test -e POSTGRES_USER=quarkus_test -e POSTGRES_PASSWORD=quarkus_test -e POSTGRES_DB=quarkus_test -p 5432:5432 postgres:13.1

Time to play with your application

You can now interact with your REST service:

  • start Quarkus with ./mvnw compile quarkus:dev

  • open a browser to http://localhost:8080/

  • search for authors or book titles (we initialized some data for you)

  • create new authors and books and search for them too

As you can see, all your updates are automatically synchronized to the Elasticsearch cluster.

Multiple persistence units

Configuring multiple persistence units

With the Hibernate ORM extension, you can set up multiple persistence units, each with its own datasource and configuration.

If you do declare multiple persistence units, you will also configure Hibernate Search separately for each persistence unit.

The properties at the root of the quarkus.hibernate-search-orm. namespace define the default persistence unit. For instance, the following snippet defines a default datasource and a default persistence unit, and sets the Elasticsearch host for that persistence unit to es1.mycompany.com:9200.

quarkus.datasource.db-kind=h2
quarkus.datasource.jdbc.url=jdbc:h2:mem:default;DB_CLOSE_DELAY=-1

quarkus.hibernate-orm.dialect=org.hibernate.dialect.H2Dialect

quarkus.hibernate-search-orm.elasticsearch.hosts=es1.mycompany.com:9200
quarkus.hibernate-search-orm.elasticsearch.version=7
quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy=write-sync

Using a map based approach, it is also possible to configure named persistence units:

quarkus.datasource."users".db-kind=h2 (1)
quarkus.datasource."users".jdbc.url=jdbc:h2:mem:users;DB_CLOSE_DELAY=-1

quarkus.datasource."inventory".db-kind=h2 (2)
quarkus.datasource."inventory".jdbc.url=jdbc:h2:mem:inventory;DB_CLOSE_DELAY=-1

quarkus.hibernate-orm."users".datasource=users (3)
quarkus.hibernate-orm."users".packages=org.acme.model.user

quarkus.hibernate-orm."inventory".datasource=inventory (4)
quarkus.hibernate-orm."inventory".packages=org.acme.model.inventory

quarkus.hibernate-search-orm."users".elasticsearch.hosts=es1.mycompany.com:9200 (5)
quarkus.hibernate-search-orm."users".elasticsearch.version=7
quarkus.hibernate-search-orm."users".automatic-indexing.synchronization.strategy=write-sync

quarkus.hibernate-search-orm."inventory".elasticsearch.hosts=es2.mycompany.com:9200 (6)
quarkus.hibernate-search-orm."inventory".elasticsearch.version=7
quarkus.hibernate-search-orm."inventory".automatic-indexing.synchronization.strategy=write-sync
1 Define a datasource named users.
2 Define a datasource named inventory.
3 Define a persistence unit called users pointing to the users datasource.
4 Define a persistence unit called inventory pointing to the inventory datasource.
5 Configure Hibernate Search for the users persistence unit, setting the Elasticsearch host for that persistence unit to es1.mycompany.com:9200.
6 Configure Hibernate Search for the inventory persistence unit, setting the Elasticsearch host for that persistence unit to es2.mycompany.com:9200.

Attaching model classes to persistence units

For each persistence unit, Hibernate Search will only consider indexed entities that are attached to that persistence unit. Entities are attached to a persistence unit by configuring the Hibernate ORM extension.

CDI integration

You can inject Hibernate Search’s main entry points, SearchSession and SearchMapping, using CDI:

@Inject
SearchSession searchSession;

This will inject the SearchSession of the default persistence unit.

To inject the SearchSession of a named persistence unit (users in our example), just add a qualifier:

@Inject
@PersistenceUnit("users") (1)
SearchSession searchSession;
1 This is the @io.quarkus.hibernate.orm.PersistenceUnit annotation.

You can inject the SearchMapping of a named persistence unit using the exact same mechanism:

@Inject
@PersistenceUnit("users")
SearchMapping searchMapping;

Building a native executable

You can build a native executable with the usual command ./mvnw package -Pnative.

As usual with native executable compilation, this operation consumes a lot of memory.

It might be safer to stop the two containers while you are building the native executable and start them again once you are done.

Running it is as simple as executing ./target/hibernate-search-orm-elasticsearch-quickstart-1.0.0-SNAPSHOT-runner.

You can then point your browser to http://localhost:8080/ and use your application.

The startup is a bit slower than usual: it is mostly due to us dropping and recreating the database schema and the Elasticsearch mapping every time at startup. We also inject some data and execute the mass indexer.

In a real life application, it is obviously something you won’t do at startup.

Offline startup

By default, Hibernate Search sends a few requests to the Elasticsearch cluster on startup. If the Elasticsearch cluster is not necessarily up and running when Hibernate Search starts, this could cause a startup failure.

To address this, you can configure Hibernate Search to not send any request on startup:

Of course, even with this configuration, Hibernate Search still won’t be able to index anything or run search queries until the Elasticsearch cluster becomes accessible.

If you disable automatic schema creation by setting quarkus.hibernate-search-orm.schema-management.strategy to none, you will have to create the schema manually at some point before your application starts persisting/updating entities and executing search requests.

Further reading

If you are interested in learning more about Hibernate Search 6, the Hibernate team publishes an extensive reference documentation.

FAQ

Why Elasticsearch only?

Hibernate Search supports both a Lucene backend and an Elasticsearch backend.

In the context of Quarkus and to build microservices, we thought the latter would make more sense. Thus we focused our efforts on it.

We don’t have plans to support the Lucene backend in Quarkus for now.

Hibernate Search Configuration Reference

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property

Type

Default

A bean reference to a component that should be notified of any failure occurring in a background process (mainly index operations).

The referenced bean must implement FailureHandler.

string

The schema management strategy, controlling how indexes and their schema are created, updated, validated or dropped on startup and shutdown.

Available values:

Strategy

Definition

none

Do nothing: assume that indexes already exist and that their schema matches Hibernate Search’s expectations.

validate

Validate that indexes exist and that their schema matches Hibernate Search’s expectations.

If it does not, throw an exception, but make no attempt to fix the problem.

create

For indexes that do not exist, create them along with their schema.

For indexes that already exist, do nothing: assume that their schema matches Hibernate Search’s expectations.

create-or-validate (default)

For indexes that do not exist, create them along with their schema.

For indexes that already exist, validate that their schema matches Hibernate Search’s expectations.

If it does not, throw an exception, but make no attempt to fix the problem.

create-or-update

For indexes that do not exist, create them along with their schema.

For indexes that already exist, validate that their schema matches Hibernate Search’s expectations; if it does not match expectations, try to update it.

This strategy is unfit for production environments, due to several important limitations, but can be useful when developing.

drop-and-create

For indexes that do not exist, create them along with their schema.

For indexes that already exist, drop them, then create them along with their schema.

drop-and-create-and-drop

For indexes that do not exist, create them along with their schema.

For indexes that already exist, drop them, then create them along with their schema.

Also, drop indexes and their schema on shutdown.

none, validate, create, create-or-validate, create-or-update, drop-and-create, drop-and-create-and-drop

create-or-validate

The strategy to use when loading entities during the execution of a search query.

skip, persistence-context, persistence-context-then-second-level-cache

skip

The fetch size to use when loading entities during the execution of a search query.

int

100

The synchronization strategy to use when indexing automatically.

Defines how complete indexing should be before resuming the application thread after a database transaction is committed.

Available values:

Strategy

Throughput

Guarantees when the application thread resumes

Changes applied

Changes safe from crash/power loss

Changes visible on search

async

Best

write-sync (default)

Medium

read-sync

Medium to worst

sync

Worst

This property also accepts a bean reference to a custom implementations of AutomaticIndexingSynchronizationStrategy.

string

write-sync

Whether to check if dirty properties are relevant to indexing before actually reindexing an entity. When enabled, re-indexing of an entity is skipped if the only changes are on properties that are not used when indexing.

boolean

true

Default backend

Type

Default

The version of Elasticsearch used in the cluster. As the schema is generated without a connection to the server, this item is mandatory. It doesn’t have to be the exact version (it can be 7 or 7.1 for instance) but it has to be sufficiently precise to choose a model dialect (the one used to generate the schema) compatible with the protocol dialect (the one used to communicate with Elasticsearch). There’s no rule of thumb here as it depends on the schema incompatibilities introduced by Elasticsearch versions. In any case, if there is a problem, you will have an error when Hibernate Search tries to connect to the cluster.

ElasticsearchVersion

Whether Hibernate Search should check the version of the Elasticsearch cluster on startup. Set to false if the Elasticsearch cluster may not be available on startup.

boolean

true

A bean reference to the component used to configure layout (e.g. index names, index aliases).

The referenced bean must implement IndexLayoutStrategy.

Available built-in implementations:

simple

The default, future-proof strategy: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex-000001, an alias for write operations named myindex-write, and an alias for read operations named myindex-read.

no-alias

A strategy without index aliases, mostly useful on legacy clusters: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex, and will not use any alias.

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See Setting up the analyzers for more information.

string

The list of hosts of the Elasticsearch servers.

list of string

localhost:9200

The protocol to use when contacting Elasticsearch servers. Set to "https" to enable SSL/TLS.

http, https

http

The username used for authentication.

string

The password used for authentication.

string

The timeout when establishing a connection to an Elasticsearch server.

Duration

1S

The timeout when reading responses from an Elasticsearch server.

Duration

30S

The timeout when executing a request to an Elasticsearch server. This includes the time needed to wait for a connection to be available, send the request and read the response.

Duration

The maximum number of connections to all the Elasticsearch servers.

int

20

The maximum number of connections per Elasticsearch server.

int

10

Defines if automatic discovery is enabled.

boolean

false

Duration

10S

The size of the thread pool assigned to the backend. Note that number is per backend, not per index. Adding more indexes will not add more threads. As all operations happening in this thread-pool are non-blocking, raising its size above the number of processor cores available to the JVM will not bring noticeable performance benefit. The only reason to alter this setting would be to reduce the number of threads; for example, in an application with a single index with a single indexing queue, running on a machine with 64 processor cores, you might want to bring down the number of threads. Defaults to the number of processor cores available to the JVM on startup.

int

green, yellow, red

yellow

How long we should wait for the status before failing the bootstrap.

Duration

10S

The number of indexing queues assigned to each index. Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

int

10

The size of indexing queues. Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

int

1000

The maximum size of bulk requests created when processing indexing queues. Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures. Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

int

100

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See Setting up the analyzers for more information.

string

green, yellow, red

yellow

Duration

10S

The number of indexing queues assigned to each index. Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

int

10

The size of indexing queues. Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

int

1000

The maximum size of bulk requests created when processing indexing queues. Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures. Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

int

100

Named backends

Type

Default

The version of Elasticsearch used in the cluster. As the schema is generated without a connection to the server, this item is mandatory. It doesn’t have to be the exact version (it can be 7 or 7.1 for instance) but it has to be sufficiently precise to choose a model dialect (the one used to generate the schema) compatible with the protocol dialect (the one used to communicate with Elasticsearch). There’s no rule of thumb here as it depends on the schema incompatibilities introduced by Elasticsearch versions. In any case, if there is a problem, you will have an error when Hibernate Search tries to connect to the cluster.

ElasticsearchVersion

Whether Hibernate Search should check the version of the Elasticsearch cluster on startup. Set to false if the Elasticsearch cluster may not be available on startup.

boolean

true

A bean reference to the component used to configure layout (e.g. index names, index aliases).

The referenced bean must implement IndexLayoutStrategy.

Available built-in implementations:

simple

The default, future-proof strategy: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex-000001, an alias for write operations named myindex-write, and an alias for read operations named myindex-read.

no-alias

A strategy without index aliases, mostly useful on legacy clusters: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex, and will not use any alias.

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See Setting up the analyzers for more information.

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See Setting up the analyzers for more information.

string

The list of hosts of the Elasticsearch servers.

list of string

localhost:9200

The protocol to use when contacting Elasticsearch servers. Set to "https" to enable SSL/TLS.

http, https

http

string

string

The timeout when establishing a connection to an Elasticsearch server.

Duration

1S

The timeout when reading responses from an Elasticsearch server.

Duration

30S

The timeout when executing a request to an Elasticsearch server. This includes the time needed to wait for a connection to be available, send the request and read the response.

Duration

The maximum number of connections to all the Elasticsearch servers.

int

20

The maximum number of connections per Elasticsearch server.

int

10

boolean

false

Duration

10S

The size of the thread pool assigned to the backend. Note that number is per backend, not per index. Adding more indexes will not add more threads. As all operations happening in this thread-pool are non-blocking, raising its size above the number of processor cores available to the JVM will not bring noticeable performance benefit. The only reason to alter this setting would be to reduce the number of threads; for example, in an application with a single index with a single indexing queue, running on a machine with 64 processor cores, you might want to bring down the number of threads. Defaults to the number of processor cores available to the JVM on startup.

int

green, yellow, red

yellow

Duration

10S

The number of indexing queues assigned to each index. Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

int

10

The size of indexing queues. Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

int

1000

The maximum size of bulk requests created when processing indexing queues. Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures. Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

int

100

green, yellow, red

yellow

Duration

10S

The number of indexing queues assigned to each index. Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

int

10

The size of indexing queues. Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

int

1000

The maximum size of bulk requests created when processing indexing queues. Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures. Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

int

100

Configuration for additional named persistence units

Type

Default

A bean reference to a component that should be notified of any failure occurring in a background process (mainly index operations).

The referenced bean must implement FailureHandler.

string

The schema management strategy, controlling how indexes and their schema are created, updated, validated or dropped on startup and shutdown.

Available values:

Strategy

Definition

none

Do nothing: assume that indexes already exist and that their schema matches Hibernate Search’s expectations.

validate

Validate that indexes exist and that their schema matches Hibernate Search’s expectations.

If it does not, throw an exception, but make no attempt to fix the problem.

create

For indexes that do not exist, create them along with their schema.

For indexes that already exist, do nothing: assume that their schema matches Hibernate Search’s expectations.

create-or-validate (default)

For indexes that do not exist, create them along with their schema.

For indexes that already exist, validate that their schema matches Hibernate Search’s expectations.

If it does not, throw an exception, but make no attempt to fix the problem.

create-or-update

For indexes that do not exist, create them along with their schema.

For indexes that already exist, validate that their schema matches Hibernate Search’s expectations; if it does not match expectations, try to update it.

This strategy is unfit for production environments, due to several important limitations, but can be useful when developing.

drop-and-create

For indexes that do not exist, create them along with their schema.

For indexes that already exist, drop them, then create them along with their schema.

drop-and-create-and-drop

For indexes that do not exist, create them along with their schema.

For indexes that already exist, drop them, then create them along with their schema.

Also, drop indexes and their schema on shutdown.

none, validate, create, create-or-validate, create-or-update, drop-and-create, drop-and-create-and-drop

create-or-validate

The strategy to use when loading entities during the execution of a search query.

skip, persistence-context, persistence-context-then-second-level-cache

skip

The fetch size to use when loading entities during the execution of a search query.

int

100

The synchronization strategy to use when indexing automatically.

Defines how complete indexing should be before resuming the application thread after a database transaction is committed.

Available values:

Strategy

Throughput

Guarantees when the application thread resumes

Changes applied

Changes safe from crash/power loss

Changes visible on search

async

Best

write-sync (default)

Medium

read-sync

Medium to worst

sync

Worst

This property also accepts a bean reference to a custom implementations of AutomaticIndexingSynchronizationStrategy.

string

write-sync

Whether to check if dirty properties are relevant to indexing before actually reindexing an entity. When enabled, re-indexing of an entity is skipped if the only changes are on properties that are not used when indexing.

boolean

true

Default backend

Type

Default

The version of Elasticsearch used in the cluster. As the schema is generated without a connection to the server, this item is mandatory. It doesn’t have to be the exact version (it can be 7 or 7.1 for instance) but it has to be sufficiently precise to choose a model dialect (the one used to generate the schema) compatible with the protocol dialect (the one used to communicate with Elasticsearch). There’s no rule of thumb here as it depends on the schema incompatibilities introduced by Elasticsearch versions. In any case, if there is a problem, you will have an error when Hibernate Search tries to connect to the cluster.

ElasticsearchVersion

Whether Hibernate Search should check the version of the Elasticsearch cluster on startup. Set to false if the Elasticsearch cluster may not be available on startup.

boolean

true

A bean reference to the component used to configure layout (e.g. index names, index aliases).

The referenced bean must implement IndexLayoutStrategy.

Available built-in implementations:

simple

The default, future-proof strategy: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex-000001, an alias for write operations named myindex-write, and an alias for read operations named myindex-read.

no-alias

A strategy without index aliases, mostly useful on legacy clusters: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex, and will not use any alias.

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See Setting up the analyzers for more information.

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See Setting up the analyzers for more information.

string

The list of hosts of the Elasticsearch servers.

list of string

localhost:9200

The protocol to use when contacting Elasticsearch servers. Set to "https" to enable SSL/TLS.

http, https

http

string

string

The timeout when establishing a connection to an Elasticsearch server.

Duration

1S

The timeout when reading responses from an Elasticsearch server.

Duration

30S

The timeout when executing a request to an Elasticsearch server. This includes the time needed to wait for a connection to be available, send the request and read the response.

Duration

The maximum number of connections to all the Elasticsearch servers.

int

20

The maximum number of connections per Elasticsearch server.

int

10

boolean

false

Duration

10S

The size of the thread pool assigned to the backend. Note that number is per backend, not per index. Adding more indexes will not add more threads. As all operations happening in this thread-pool are non-blocking, raising its size above the number of processor cores available to the JVM will not bring noticeable performance benefit. The only reason to alter this setting would be to reduce the number of threads; for example, in an application with a single index with a single indexing queue, running on a machine with 64 processor cores, you might want to bring down the number of threads. Defaults to the number of processor cores available to the JVM on startup.

int

green, yellow, red

yellow

Duration

10S

The number of indexing queues assigned to each index. Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

int

10

The size of indexing queues. Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

int

1000

The maximum size of bulk requests created when processing indexing queues. Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures. Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

int

100

green, yellow, red

yellow

Duration

10S

The number of indexing queues assigned to each index. Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

int

10

The size of indexing queues. Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

int

1000

The maximum size of bulk requests created when processing indexing queues. Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures. Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

int

100

Named backends

Type

Default

The version of Elasticsearch used in the cluster. As the schema is generated without a connection to the server, this item is mandatory. It doesn’t have to be the exact version (it can be 7 or 7.1 for instance) but it has to be sufficiently precise to choose a model dialect (the one used to generate the schema) compatible with the protocol dialect (the one used to communicate with Elasticsearch). There’s no rule of thumb here as it depends on the schema incompatibilities introduced by Elasticsearch versions. In any case, if there is a problem, you will have an error when Hibernate Search tries to connect to the cluster.

ElasticsearchVersion

Whether Hibernate Search should check the version of the Elasticsearch cluster on startup. Set to false if the Elasticsearch cluster may not be available on startup.

boolean

true

A bean reference to the component used to configure layout (e.g. index names, index aliases).

The referenced bean must implement IndexLayoutStrategy.

Available built-in implementations:

simple

The default, future-proof strategy: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex-000001, an alias for write operations named myindex-write, and an alias for read operations named myindex-read.

no-alias

A strategy without index aliases, mostly useful on legacy clusters: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex, and will not use any alias.

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See Setting up the analyzers for more information.

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See Setting up the analyzers for more information.

string

list of string

localhost:9200

The protocol to use when contacting Elasticsearch servers. Set to "https" to enable SSL/TLS.

http, https

http

string

string

The timeout when establishing a connection to an Elasticsearch server.

Duration

1S

Duration

30S

The timeout when executing a request to an Elasticsearch server. This includes the time needed to wait for a connection to be available, send the request and read the response.

Duration

int

20

int

10

boolean

false

Duration

10S

The size of the thread pool assigned to the backend. Note that number is per backend, not per index. Adding more indexes will not add more threads. As all operations happening in this thread-pool are non-blocking, raising its size above the number of processor cores available to the JVM will not bring noticeable performance benefit. The only reason to alter this setting would be to reduce the number of threads; for example, in an application with a single index with a single indexing queue, running on a machine with 64 processor cores, you might want to bring down the number of threads. Defaults to the number of processor cores available to the JVM on startup.

int

green, yellow, red

yellow

Duration

10S

The number of indexing queues assigned to each index. Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

int

10

The size of indexing queues. Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

int

1000

The maximum size of bulk requests created when processing indexing queues. Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures. Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

int

100

green, yellow, red

yellow

Duration

10S

The number of indexing queues assigned to each index. Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

int

10

The size of indexing queues. Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

int

1000

The maximum size of bulk requests created when processing indexing queues. Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures. Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

int

100

About the Duration format

The format for durations uses the standard java.time.Duration format. You can learn more about it in the Duration#parse() javadoc.

You can also provide duration values starting with a number. In this case, if the value consists only of a number, the converter treats the value as seconds. Otherwise, PT is implicitly prepended to the value to obtain a standard java.time.Duration format.

About bean references

When referencing beans using a string value in configuration properties, that string is parsed.

Here are the most common formats:

  • bean: followed by the name of a @Named CDI bean. For example bean:myBean.

  • class: followed by the fully-qualified name of a class, to be instantiated through CDI if it’s a CDI bean, or through its public, no-argument constructor otherwise. For example class:com.mycompany.MyClass.

  • An arbitrary string referencing a built-in implementation. Available values are detailed in the documentation of each configuration property, such as async/read-sync/write-sync/sync for quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy.

Other formats are also accepted, but are only useful for advanced use cases. See this section of Hibernate Search’s reference documentation for more information.