Today we released yet another milestone for the Hibernate Search 5 train. We worked in parallel on multiple fronts; the most notable changes are:

OSGi support, API changes

All our modules now provide OSGi metadata to make life easier for users running in OSGi containers. We also included an example features file and integration tests using Karaf.

Keep in mind that Apache Lucene is not providing this same metadata, so it might be worth looking into the features file we use to learn how the Lucene modules need to be wrapped.

Class Relocations

A consequence of being OSGi compliant is that we had to move some packages of well-known APIs; please see the migration guide for all details.

Apache Lucene 4.8.1, Java7 now required

Apache Lucene requires Java7 since version 4.8 and we don't want you to miss out some of the great improvements it provides, or potential bugfixes in the near future so we now require Java7 too.

Apache Lucene 4.8.1 was released today, so we could include it in this release too.

Bridge Providers loaded by auto-discovery

We always had a strong differentiation between FieldBridge(s) included in Hibernate Search, and custom (application provided) FieldBridges. From this release the discovery of built-in bridges uses the Service Loader pattern, so that we can move some bridge implementations to optional modules, and also eventually provide support for the new date/time types defined in Java8 but also by Joda Time, and potentially your own custom types but this will need some further refinement work.

Several other improvements

These won't make the headlines as a Java requirements change, still we have some more relevant news:

  • Infinispan upgraded to 7.0.0.Alpha4: now also requires Java7 and supports the distributed Lucene Directory for Apache Lucene 4.8
  • the needed Infinispan update implies using latest JGroups 3.5.0.Beta5
  • all our documentation was migrated to AsciiDoc , it's now much easier to contribute to documentation!
20. May 2014, 20:05 CET | Link
This is great!
One Question, but more related to ORM and OSGI.
It will be possible in Hibernate 5, dynamic loading of entities in a single persistence unit, without the need to stop the bundle?

Thank you!
21. May 2014, 22:51 CET | Link

Cristian, can you clarify exactly what you mean by that?

22. May 2014, 20:26 CET | Link

Brett: Hello, the question is:

I have a Bundle (Kernel) which handles all persistence. Then I have n Bundles, which have their own persistent classes (Entities). These bundles will be installed in as needed. The question is, once initialized persistence in Bundle (Kernel) is possible without restarting add new entities that expose other Bundles? For example: Which Persistence Unit now recognize a new place to find classes?


22. May 2014, 22:53 CET | Link

Hi Cristian, I might be wrong but I don't think that is conceptually possible to achieve (correctly), unless all entities are absolutely independent (no inheritance relations, and no relations at all) across bundles which have an independent lifecycle. My reasoning is that a relation to an entity might affect the schema definitions.

But if the modules are entirely independent, you could as well start independent instances of Hibernate. Bear with me if I'm missing something, I'm not familiar with the dynamic capabilities of OSGi.