While working on Hibernate Search 3.3, we have discovered a critical issue with Hibernate 3.2. If you use Hibernate Core 3.5 in a JTA environment (recommended), the way Hibernate Search 3.2 registers itself can lead to inconsistent indexing and generate assertion failures. All this is fixed in Hibernate 3.2.1 which you can get here and ported to trunk as well. We have also added tests to cover the JTA area.

We highly recommend people using Hibernate Search 3.2.0 to migrate to 3.2.1.

For more information on this bug and others fixed in 3.2.1, check out the changelog.

Many thanks to Tom Waterhouse for helping us all along the discovery, fix and testing process.

Hibernate Search 3.2 has been in development close to a year and now we are releasing it :) Instead of giving you a list of new features, let me highlight a couple of use cases we now cover:

Defining index mappings depending on customer / deployment

The primary way to express index mappings in Hibernate Search is via annotations. This works 95% of the time, but in some cases you want to adjust what gets indexed and how in a more fine grained way. For example:

• you deliver the same application to different customers and want to give them the opportunity to configure some of the available indexed properties
• you deploy the same domain model in different apps where each needs specific search capabilities

To achieve this, we have introduced an easy to use, easy to read fluent programmatic API to express index mappings. Check out the programmatic API in the reference documentation or this blog entry.

Index/reindex my data easy and fast

In Hibernate Search, there has been a couple of best practices to initially index your data. You needed to read your data from the database in batch, call the index operation, flush and clear the session and move on to the next batch.

Forget that now. We have a super easy API to index or reindex your data (as simple as two method calls). You can also configure how indexing is done via an intuitive fluent API (yes we've catched the fluent API virus and you haven't seen the end of it). Not only is the new approach easy to use but it's also massively faster than the previously recommended best practices. We highly recommend people to move to this new approach.

Check out the reference documentation or this blog entry for more info.

I can't use JMS, but I need index clustering

Let me first state that setting up a JMS queue is super simple and trivial in any of the modern application servers ( esp JBoss AS :) ) and you get tons of benefits from it (reliability etc). Of course, if you like to waste time and build your own stack on top of Tomcat or equivalent, too bad for you.

Anyways, you can now use an alternative approach to JMS for clustering. We now support raw JGroups communications between cluster members.

My sysadmin needs a way to see what indexing operation have failed and restart them

Luckily that does not happen often but when indexing failures happen, we need to do something about them.

You now have access to an API to listen to indexing errors and process them as you please. The default implementation logs the error but you can easily decide to push the errors to some queue for display or replay, send a message via SNMP etc etc. The actual error is provided as well as the list of entities that should have been processed (quite handy for replay).

I have a single instance updating the index, can I make it faster?

Yes, if a single instance of Hibernate Search is responsible to update the index, we can speed up things. Simply add

hibernate.search.[default|index name].exclusive_index_use true

What else?

Hibernate Search 3.2 runs on Hibernate Core 3.5 and JPA 2. And as always we did many more things for this release including various optimizations, bug fixes, simplifying the Hibernate Search settings (especially for dependencies), adding a simpler API for bridges.

Check out on the web site, download Hibernate Search or browse the reference documentation. We also have a migration guide from earlier versions of Hibernate Search.

PS: For the Maven users, JBoss has migrated to a new maven repository. Read this user guide to know more.

PPS: We are already on Hibernate Search 3.3. Stay tuned.

I am happy to announce the release of Hibernate Search 3.2 CR1. Crossing fingers, this is the latest release before the final version targeted in a few days.

A good 75% of our time has been spent on bug fixes fresh and old (some even fossilized). But we have also added a few interesting new features:

• we have polished the one we introduced in 3.2 Beta1
• we moved to Lucene 2.9 APIs as a first step towards Lucene 3.0's migration and we also have upgraded to Solr 1.4 for the declarative analyzer framework
• Amin, Sanne and I have been working on a new API to catch and process indexing errors: the default implementation logs the errors but you can write your own custom callback. You could log the failing indexing process to a DB, send a message to a sysadmin, queue the issues for automatic reprocessing etc).
• Hibernate Search 3.2 targets Hibernate Core 3.5 and use some of the new APIs
• a simpler API is at your disposal to add fields to a Lucene document in your custom bridges (thanks Sanne!)

You can download the release from sourceforce or our maven repository and read the documentation. Try it out!

Many thanks for the bug reports / feature requests you have send us: they helped polish this release. Atop the usual suspects, I would like to thank Gustavo Nalle Fernandez and Amin Mohammed-Coleman for their contribution.

It was bound to happen, the minute I announced the Wicket integration, I've received a few emails describing integrations with other frameworks (like Tapestry). I've created a wiki page to list all frameworks integrating Bean Validation and a pointer to their documentation. Go ahead and fill it up with any active integration you are aware of. The page is here.

People following our work and vision on Bean Validation know that the ultimate goal is to get the ecosystem of Java frameworks to natively integrate Bean Validation where it makes sense. A particularly important area is the the presentation layer that should call Bean Validation to validate the values to be put in the domain model.

This is a feature we have added in JSF 2 and I am happy to see the model being embraced by other frameworks. A new addition to the game is Wicket: Zenika has created a project to integrate Bean Validation in Wicket just like we did for JSF. It's all explained here.

If I may, my next wish is to get rid of this annoying lonely line:

personForm.add(new JSR303FormValidator());

Just get it to work out of the box :) Aside from this detail, this is exactly how a component based framework should integrate Bean Validation. great work.