Problems migrating from 5.11 to 6.x

i’ve problems migrating two configuration properties:
i cant find an entry for this property in the migration-guide. Is it not possible anymore to register a factory?
this property moved to I used this property to register an own directory provider by implementing a class implementing the interface Is there a similar way to do this with version 6.x?

Hey Markus, thanks for reaching out. It’s great that you are switching to the newer version. As there are a lot of configuration options exposed for both mass indexer and directory provider, I’d like to ask if you could also share what is currently missing from the built-in functionality that you’d still want to provide your custom implementations for the things you’ve mentioned.

Then to try answer your question:

I don’t think that there’s any alternative available for this right now.

Even though the documentation provides only two options: local-filesystem and local-heap for this property you could actually pass a fully qualified class name of your own implementation and it’ll be instantiated and used. With that said I would still encourage you to check if the config properties for directories would cover your needs instead of providing the custom implementation.

What exactly do you achieve with your custom That might be an interesting information for the team.

I used the factory for two reasons:

  • i have added a CDI context to the threads because I needed the context in some bridges
  • In a multitenancy environment, the threads were set to a specific tenant, so that I could get discrete index files for the same entities from different tenants

if there were already better solutions or now there are, I would of course be grateful for tips :slight_smile:

Regarding DirectoryProvider… we determine the storage location for certain reasons from a microprofile-config property. The DirectoryProvider was ideal to use for this.
In the medium term we will switch to Elasticsearch or OpenSearch. It would be nice if there was also a possibility here to be able to define the configuration parameters via a corresponding provider.


MassIndexerFactory was an SPI whose only known use was in Hibernate OGM, with no other clear use case, so it was not reimplemented in Hibernate Search 6. Let’s see how to address your use case in Hibernate Search 6, though.

I suspect [HSEARCH-1809] - Hibernate JIRA would address that, should someone send a PR. It would probably be relatively easy to implement.

I’m not sure what you were doing exactly, but I think you basically want index-based multitenancy, e.g. one Lucene index per tenant? We don’t have that feature planned at the moment, but that’s certainly a reasonable one, so feel free to create a ticket.

In the meantime, you can probably make it work with a routing bridge? You have access to the tenant identifier in the RoutingBridge.route(...) method through context.tenantIdentifier().

So this is about configuring Hibernate Search based on other sources than just the Hibernate ORM configuration?

While it would technically be possible to provide such integration points, I decided against it because there are already plenty of solutions to pre-process external configuration and turn it into Hibernate Search configuration in frameworks and Hibernate ORM itself: Spring’s has a PropertyResolver, Quarkus/MicroProfile has custom ConfigSources, but there are also ways to override Spring’s JPA bootstrap to inject additional properties, and Hibernate ORM allows overriding the default ConfigurationServie through your own implementation of StandardServiceInitiator<ConfigurationService> if necessary.

If that’s not enough… as Marko mentioned, you can always set to a custom implementation of But that’s a low-level SPI, so you can expect more frequent and drastic changes than in APIs.