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

I will be giving a talk at the Atlanta JUG next Tuesday (18th).

The talk will go through Hibernate Search: why using it, where to use it, it's internal architecture and how to use it best.

I will also introduce Hibernate Shards, what it is and what it is not :)

Hopefully Q&A will have a decent slice of the time cake.

See you in the Perimeter area :)

Hibernate Search 3.0.0.CR1 is now out. This release is mainly the last bits of new features and polishing before the final version. The next cycle will be dedicated to bug fixes (of any bug that pops up), as well as test suite and documentation improvements.

Thanks to Hardy for the new getting started guide (this should ease the path for newcomers), and to John for hammering the last features we wanted in the GA version:

  • /manual indexing/ you can disable event based indexing: useful when the
  • /purge/ you can remove an entity from the index without affecting the database. This is especially useful if you take care of the indexing manually (using a timestamp method for example)

The next version should be the GA release unless some complex bugs are discovered.

Check the changelogs for a detailed change list.

Hibernate Search has a new beta out and comes with a bunch of interesting new features:

  • Named filters: custom filters on query results (transparently cacheable)
  • Automatic index optimization
  • Access to query metadata (Score, ...)
  • Support for the Java Persistence API
  • Index Sharding (indexing an entity into several underlying Lucene indexes)

Named filters

Based on Lucene filters, named filters provide the ability to apply custom filter restrictions to the query results. Enabled by name and parameters (very much like Hibernate Core filters), filters are cacheable to improve performance. Some noticeable use cases are security, temporal data, restriction by population, query within query results.

Automatic index optimization

Hibernate Search can transparently optimize your index after a certain amount of operations (add, delete) or transactions.

Query result metadata

The projection API has been enhanced to return query specific data like the document score (relevance) and a few other metadata.

Support for the Java Persistence API

There is now a FullTextEntityManager and FullTextQuery (extending javax.persistence.Query). No need to access entityManager.getDelegate() anymore.

Index sharding

In extreme cases, Lucene indexes need to be split into several physical indexes. Hibernate Search can now index a given entity to several underlying Lucene indexes.

And a few more

There are a few more additional features:

  • Ability to index a given property in multiple different fields with different settings (without the need for a custom FieldBridge)
  • Fine grained analyzers (global, per entity, per property or per field)
  • Expose Lucene merge factor, max merge doc and max buffered docs
  • Ships with Lucene 2.2

Thanks to John Griffin and Hardy Ferentschik for stepping up on this release. The feature set is up to what was envisioned for the final release (much more actually) and has proven very stable. We expect a short CR cycle and the GA soon after.

Check out here for more info. The download page is here .

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.

Showing 81 to 85 of 98 blog entries