I'm the person behind annotations in Hibernate: Hibernate Annotations, Hibernate EntityManager, Hibernate Validator and Hibernate Search. I am a member of the JPA 2.0 expert group as well as the JSR-303 Bean validation spec lead. You can check out my book Hibernate Search in Action by Manning.

Location: CET
Occupation: Core developer at JBoss, by Red Hat
My Links

Hibernate Search 3.0.0.Beta2 is out with a bunch of new interesting features:

  • shared Lucene IndexReader, significantly increasing the performances especially in read mostly applications
  • ability to customize the object graph fetching strategy
  • properties projection from the Lucene index
  • ability to sort queries (thanks to Hardy Ferentschik)
  • expose the total number of matching results regardless of pagination


Hibernate Search can now share IndexReaders across queries and threads, making them much more efficient especially on applications where the number of reads is much higher than the number of updates. Opening and warming a Lucene IndexReader can be a relatively costly operation compared to a single query. To enable sharing, just add the following property shared

Object loading has been enhanced as well. You can for example define the exact fetching strategy used to load the expected object graph, pretty much like you would do it in a Criteria or HQL query, allowing per use case optimization.

Some use cases do not mandate a fully loaded object. Hibernate Search now allow properties projection from the Lucene index. At the cost of storing the value in the index, you can now retrieve a specific subset of properties. The behavior is similar to HQL or Criteria query projections.

fullTextQuery.setIndexProjection( "id", "summary", "body", "" ).list();

Query flexibility

I already talked about the customizable fetching strategy and projection.

The default sorting on Hibernate Search queries is per relevance, but you can now customize this strategy and sort per field(s).

Regardless of the pagination process, it is interesting to know the total number of matching elements. While costly in plain SQL, this information is provided out-of-the-box by Apache Lucene. getResultSize() is now exposed by the FullTextQuery. From this information, you can for example:

  • implement the search engine feature '1-10 of about 888,000,000'
  • implement a fast pagination navigation
  • implement a multi step search engine (gradually enabling approximations if the restricted query(ies) return no or not enough results)

For more information, check the the release notes and download the bundle . Hibernate Search 3.0.0.Beta2 is compatible with Hibernate Core 3.2.x (from 3.2.2), Hibernate Annotations 3.3.x and Hibernate EntityManaher 3.3.x.

07. May 2007, 23:01 CET, by Emmanuel Bernard

With the new Groovy 1.1 beta out and its support for Java 5 annotations, wouldn't it be great to be able to write Seam applications in Groovy? Indeed it is great and you can do that with JBoss Seam (in CVS HEAD at the time of writing).

What is supported, how does it work?

You can write any entity and any action in Groovy. By simply annotating your Groovy classes with Seam annotations, they become Seam components.

class BookingListAction implements Serializable
    @In EntityManager em
    @In User user
    @DataModel List<Booking> bookings
    @DataModelSelection Booking booking
    @Logger Log log

    @Factory public void getBookings()
        bookings = em.createQuery('''
                select b from Booking b
                where b.user.username = :username
                order by b.checkinDate''')
            .setParameter("username", user.username)
    public void cancel()
    {"Cancel booking: #{} for #{user.username}")
        Booking cancelled = em.find(Booking.class,
        if (cancelled != null) em.remove( cancelled )
        FacesMessages.instance().add("Booking cancelled for confirmation number #{}", new Object[0])

En passant, you can use Groovy to write your Entities, Hibernate support them out of the box. No constraint, no limitation, no XML ;-)

class Hotel implements Serializable
    @Id @GeneratedValue
    Long id

    @Length(max=50) @NotNull
    String name

    @Length(max=100) @NotNull
    String address

    @Length(max=40) @NotNull
    String city

    @Length(min=2, max=10) @NotNull
    String state

    @Length(min=4, max=6) @NotNull
    String zip

    @Length(min=2, max=40) @NotNull
    String country

    @Column(precision=6, scale=2)
    BigDecimal price

    String toString()
        return "Hotel(${name},${address},${city},${zip})"

Groovy files are compiled by the groovyc compiler in your build system ; they then appear like regular classes to the container.

Push it even Groovier

Let's go further, when Seam is in development mode, the .groovy files can be deployed as is with no groovyc build time compilation involved. Like hot redeployable Java Seam components, deploy (and I mean copy) your .groovy files in your WEB-INF/dev directory.

No need to restart the application (not even speaking of the container): the next hit will reload the Groovy classes transparently providing a pretty smooth development environment. Fast development time, fast deployment time.

This mode is currently limited to Seam JavaBean components: EJB 3.0 Session Beans and Entities do not (yet) support hot redeployment. We are considering enhancing the JBoss EJB 3 container to get rid of this limitation (you will still hit this limitation in other containers though).

How can I set that up?

By using seam-gen, you can generate a ready to use development environment supporting Groovy in a minute.

./seam setup
# use project type WAR, the rest is at your will

./seam new-project
# that's it

And you are done, feel free to write .groovy code in either src/model or src/action Remember in Seam development mode, you don't have to restart the application when you change code in src/action (whether it be Groovy or Java). A simple ./seam explode (to copy the Groovy files) will do the trick.

For a complete working Groovy project, have a look at the groovybooking project in JBoss Seam examples (CVS HEAD at the time of writing).

This feature (already available in CVS HEAD) is expected for the next major JBoss Seam release: we still have some more surprises in our bag :-)

NB: if you are interested in Groovy and are in San Francisco tonight, don't miss the G2One , I will be there if you have any question.

19. Apr 2007, 23:37 CET, by Emmanuel Bernard

Hibernate and JBoss Seam will be covered by some of the JBoss folks at JavaOne.

Hibernate Search

TS-4746 - Hibernate Search: Googling Your Java Technology-Based Persistent Domain Model

I will describe the problem addressed, how Hibernate Search backed by Apache Lucene provides a solution, the internal architecture and some tips and tricks. I will also demo how to add Hibernate Search to an application.

Hibernate Validator and JSR-303

TS-4112 - Declarative Programming: Tighten Enterprise JavaBeans (EJB) 3.0 and JSR 303 Beans Validation

I will provide an update about JSR-303 Bean Validation and Hibernate Validator, how it will fit into the Java SE/Java EE world. I will also demo how to use it today with EJB 3.0 interceptors.

JBoss Seam

TS-4089 - Web Beans Update

Gavin will talk about Web Beans, the standardization process around JBoss Seam.

BOF-4400 - Improve and Expand JavaServer Faces Technology with JBoss Seam

BOF-9792 - Rapid Seam Application Development with the NetBeans IDE

Michael will also talk about JBoss Seam, the product. These tracks are more focused on JBoss Seam ease of use and Rapid Application Development (this is what JBoss Seam is about after all ;- ) )

Check the JavaOne website or the JBoss website for more info.

I think a party is planed too, see you there.

20. Mar 2007, 18:38 CET, by Emmanuel Bernard

This is a pretty big day for the Hibernate family. We welcome three new top level projects:

  • Hibernate Shards
  • Hibernate Validator
  • Hibernate Search

So total we have made five new releases today .

Hibernate Shards 3.0.0 Beta1

Contributed by Google, Hibernate Shards is a horizontal partitioning solution built on top of Hibernate Core. When you need to distribute (shard) your data across multiple databases, Hibernate Shards is for you (too much data for a single database instance, regional deployment requirements, etc.) Like all Hibernate projects, Hibernate Shards is released under the LGPL license. Big thanks to Max Ross, Maulik Shah Tomislav Nad, and Google :-) for contributing back to the community their pretty impressive Google's 20 percent project.

Check the documentation for more information.

Hibernate Search 3.0.0.Beta1

Hibernate Search is now a top level project independent of Hibernate Annotations. New in this release:

  • out of the box index clustering through JMS - master/slaves model -(maximizing throughput)
  • asynchronous indexing (maximizing application response time)
  • indexing of embedded/associated objects and correlated queries (semantically similar to a SQL JOIN)
  • use of Apache Lucene(tm) 2.1.0 (lot's of performance and scalability improvements)

While marked as Beta because its scope is rapidly growing and some APIs are still subject to change, Hibernate Search is already used by quite a few people, check it out .

Hibernate Validator 3.0.0.GA

Hibernate Validator is also a new top level project independent of Hibernate Annotations. New in this release:

  • run with pure Java Persistence Provider (entity listener provided)
  • more business oriented validators

Check the website and the change log for more information.

Hibernate Annotations and Hibernate EntityManager 3.3.0.GA

A few minor configuration changes (necessary to introduce the previous projects) lead us to an version number increase. This version is however mostly backward compatible with 3.2.x. Some of the new features are listed:

  • transparent event wiring for Hibernate Validator and Hibernate Search
  • performance improvements during cascading in Hibernate EntityManager
  • more SQL customizations as well as fetching and lazy configurations
  • the usual bunch of bug fixes

The past few months have been pretty busy preparing this unique feature rich Hibernate bundle with smooth out of the box experience. Enjoy :-)

The most significant part, by far, of Hibernate Annotations 3.2.1 is the complete rewriting and feature expansion of Hibernate Search formerly known as Hibernate Lucene.

Long story short

Hibernate Search allows you to search your domain model (google it) without the hassle and mismatches introduced by the full text technology. Indexing is done automatically, the mapping between the object model and the index documents is described through annotations, the querying capability is integrated with the regular Hibernate querying system. Hibernate Search use Apache Lucene underneath and lowers the barrier to entry to such a technology technology.

What is it all about

In a few words, bringing Google search capabilities to your domain model.

For most people, queries are synonym of SQL query, and this is indeed the case of most applications. There is a spectrum of queries, however, that are not handled by SQL (at least without proprietary extension): free text search, proximity search, phrase search, synonyms, approaching terms, result by relevance... Full-text search engines solve these classes of problems.

Full text search queries involve two steps. Indexing, ie maintain coherence between the database information and the full text index information. Querying, the ability to query in a free form the indexed information.

Integrating such a search capability to a system is not that easy. In most systems, a mismatch exists between the data structure used by the application core and the data structure used by the full text search. For applications using ORM such as Hibernate, the former is mostly designed around the object model, while the latter is designed around the notion of documents containing several fields of strings. Handling this mismatch and maintaining the data synchronized between both part of the system tend to be too tedious for a massive adoption.

Hibernate Search aims to tackle the mismatch complexity for you, and to lower the barrier to entry of full text technology such as Apache Lucene in most applications.


Hibernate Search is a glue code between Hibernate and Apache Lucene. Apache Lucene is a fantastic full-text index Java library, and the de facto standard in the open source world. Hibernate Search listen to any changes made to the domain model thanks to the Hibernate event model. All modifications made to your persistent objects will be propagated to the Apache Lucene index transparently. Under the hood, Hibernate Search is optimizing indexing by batching the works. The current implementation queue the work per transaction. Other pluggable implementations will be possible shortly. Finally, you can force indexing of a given set of objects, which is particularly useful when initializing the index. How indexes are organized is pretty much up to you, you can have one Directory (index) per entity type (recommended) or share the same Directory for several entities.


Indexing means translating the java object attributes to a (potentially degraded) string representation. The bridge between properties and index fields is driven by annotations metadata and defaulted to a built-in set of bridges. Flexibility is provided by the ability to use a custom bridge (very similar to the notion of /UserType/).


One of the mismatch is that full text queries in Apache Lucene returns /Documents/ and not regular domain objects. Hibernate Search implements /org.hibernate.Query/ and gives you a unified query model regardless of the query engine (criteria, HQL, SQL, Lucene). In particular, you have access to pagination and all the query APIs like /scroll()/, /list()/ etc... All queries will return managed objects (ie attached to a session), that you will be able to use and modify at will like a regular hibernate managed object (because it /is/ a regular managed object). You can decide to query on all entities or only a subset of them. Like in Hibernate, querying on a subset of entities is polymorphic.

Try it out

Hibernate Search goal is really to lower the barrier to entry of full text engine technology. Apache Lucene is often criticized by beginners for its low level API and inherent complexity. Hibernate Search make it simple to use, removing some of the complexity, but let you access all the power and flexibility of Apache Lucene if you need to. Hibernate Search is part of Hibernate Annotations. Check it out and download it , using it is much simpler than explaining it :-)

Showing 81 to 85 of 95 blog entries