We just published 5.10.0.Final, the first stable release in the 5.10 branch. This release brings an upgrade of the ORM integration to ORM 5.3 and JPA 2.2, an integration to DI frameworks through Hibernate ORM 5.3, an upgrade to WildFly 12 and JGroups 4, and JPMS automatic module names.

What’s new?

If you didn’t pay attention after the 5.9.0.Final release, then there is a lot of news for you! Below is a summary of notable changes since 5.9.

If you tried out the Betas/CR, know that this release only adds two changes on top of 5.10.0.CR1:

  • HSEARCH-3159: Hibernate Search’s ORM integration now depends on Hibernate ORM 5.3.0.Final.

  • HSEARCH-3156: @ContainedIn will not fail anymore at runtime when targeting a class for which only some subclasses are configured in Search.

ORM 5.3 and JPA 2.2 compatibility

Hibernate Search 5.10 is designed to work with Hibernate ORM 5.3.

Integration to DI frameworks through Hibernate ORM 5.3

Hibernate Search now taps into Hibernate ORM’s integration to dependency injection frameworks. If you use a dependency injection framework integrating with Hibernate ORM 5.3, and you add field bridges to your dependency injection context, then Hibernate Search will automatically retrieve and use field bridges from this context.

This allows you in particular to inject components from your DI context into your field bridges, using your DI framework’s features (@java.inject.Inject, Spring’s @Autowired, …​).

The integration is already known to work in a CDI 2.0 environment such as WildFly 12, and the Spring team will probably make it work as soon as it adds support for JPA 2.2.

Upgrade to WildFly 12 and JGroups 4

Hibernate Search’s JBoss modules now target WildFly 12. This means in particular that the JGroups backend now uses JGroups 4 and is no longer compatible with JGroups 3.

Also, we took this opportunity to move the JGroups backend’s JBoss modules out of the engine feature pack to a dedicated feature pack.

JPMS automatic module names

We added automatic JPMS module names to our JARs.

Note that Hibernate Search JARs still can only be used as automatic modules, because some of our dependencies cannot easily be used as modules yet.

Here are the module names:

  • org.hibernate.search.engine

  • org.hibernate.search.orm

  • org.hibernate.search.backend.elasticsearch

  • org.hibernate.search.backend.elasticsearch.aws

  • org.hibernate.search.clustering.jms

  • org.hibernate.search.clustering.jgroups

  • org.hibernate.search.jsr352.core

  • org.hibernate.search.jsr352.jberet

  • org.hibernate.search.serialization.avro

Direct access to the Elasticsearch client

Hibernate Search now offers a way to access the Elasticsearch client directly. See the documentation for more information.

Other changes

Here are the other notable changes since Hibernate Search 5.9.0.Final:

  • HSEARCH-3026: If your Elasticsearch cluster is accessed through a URL with a non-root path, you can now use hibernate.search.default.elasticsearch.path_prefix to tell Hibernate Search about that path.

  • HSEARCH-3039: We removed the ability to analyze document identifiers from Search a few versions ago, but some parts of Hibernate Search still performed analysis on document identifiers in some cases, in particular when querying them and when embedding a document ID using @IndexedEmbedded. This has been fixed: Hibernate Search now consistently skips analysis on document identifiers.

  • HSEARCH-3021: The integration to dependency injection frameworks is now properly documented.

  • HSEARCH-3138: We restored binary compatibility with applications built against Hibernate Search 5.5, so that Hibernate Search 5.10 can be included in the upcoming WildFly release.

For a full list of changes since 5.9.0.Final, please see this list of tickets on our JIRA instance.

For a full list of changes since 5.10.0.CR1, please see the release notes.

How to get this release

All details are available and up to date on the dedicated page on hibernate.org.

Next

We are still working on Hibernate Search 6, with the proof of concept now providing both an Elasticsearch and a Lucene backend, with generic APIs that will avoid the need to add Lucene to your classpath when you only need Elasticsearch.

There is still a lot of work to do, but we expect to be able to release an Alpha in the next few months.

Feedback, issues, ideas?

To get in touch, use the following channels:


Back to top