Red Hat

In Relation To Emmanuel Bernard

In Relation To Emmanuel Bernard

Hibernate team au ParisJUG

Posted by Emmanuel Bernard    |       |    Tagged as Events

Some of the Hibernate team members all gather together next week in Paris.

If you are around, come join us for a Questions & Answers session at the ParisJUG. It’s Tuesday December 2nd 2015 at 19:30. We will discuss anything Hibernate, no slide, simply come with your questions on:

  • Hibernate ORM

  • Hibernate OGM

  • Hibernate Search

  • Hibernate Validator / Bean Validation

  • Persistence

  • past, present, future

  • …​

Registration to the session is required but free. Hope to see you there to exchange.

Red Hat 4 Kids

Posted by Emmanuel Bernard    |       |    Tagged as Off-topic Events

I am ending my day totally exhausted but happy. Today we organised Red Hat 4 Kids in the Red Hat France office.

Every year at Red Hat, we organise a Red Hat Week to celebrate our culture. And in good open source community way, each local office expresses how it pleases this event. This year, I proposed to do a Devoxx4Kids for the children of French Red Hatters.

Red Hat 4 Kids (aka a copy paste of Devoxx 4 Kids) initiates children from 6 to 12+ to the notion of programming. Sharing our knowledge to teach them what daddy or mummy does. Sounds cool.

Scratch workshop

I knew it was doable since the awesome Devoxx4Kids team has successfully declined these events around the world. But my engineering spider-senses told me it would be quite a humongous task. I was right but it’s one of those projects where you need to jump first and think later.

What did we do?

For the 6 to 10 years old boys and girls, we have done a Scratch workshop. Scratch is awesome, it has all the basics of programming: blocks, loops, conditions, events, event sharing, etc…​ Here, not need to prepare much, explain the basics and let the kids go (see below).

For the 10+ kids, we have done the Arduino workshop: programming electronics for the win :) We have reused the Devoxx4Kids one verbatim.

We were also lucky to have the Aldebaran team with us. So the kids moved up from the basics of programming to full Nao robot programming. Nao is a serious guest start and actually easier to program than Scratch :)

What are the challenges?

You need to prepare everything material wise

We installed a fresh Fedora 22 on all laptops to get everything set up the same: this really helped as we did not have to fight different environments. To be safe, we used ethernet and not WiFi: some WiFi routers don’t enjoy too many laptops at once.

Don’t go too long

For the 6-10 years old, they started to slowly drift after one hour. Don’t go over 1h30 per workshops and do breaks between them. For the 10+, they actullally went beyond our 1h30 and chose coding over cakes: success!

Limit the introduction and slides as much as possible

Developers don’t like slides. It turns out kids disregard them after 4 mins top. I had to cut the presentation quickly and instead…​

Do customized assistance

Show them by pair-kid-programming how to do the basic things and let them do what they want: help them achieve their goal: story, adventure, games etc…​ One grown up for one to two laptops, two kids per laptops. Max. They will be much more engaged.

Special thanks

It’s quite a special feeling to see a good chunk of the kids being that engaged, asking tougher and tougher questions over time and preferring coding to cakes.

I have many people to thank for this project. Hopefully I won’t forget too many of them:

  • the Devoxx4Kids team for putting their workshop in open source

  • Audrey and Arun from Devoxx4Kids for giving me customized advice and reassuring me along the way

  • the Red Hat French facilities team for saying yes to this project and putting up with all the material challenges (room size, power outlets, laptop hunt, mouse chasing, etc.)

  • the local Red Hat techies for gathering the hardware, installing the machines, testing everything and helping out during the workshops

  • last be not least, the Aldebaran team for being part of the fun

Nao in action

Just Fracking do it

Don’t think, do it. Go to and start from their workshops.

Handling queries on complex types in Hibernate Search

Posted by Emmanuel Bernard    |       |    Tagged as Hibernate Search

Writing queries using complex types can be a bit surprising in Hibernate Search. For these multi-fields types, the key is to target each individual field in the query. Let’s discuss how this works.

What’s a complex type?

Hibernate Search lets you write custom types that take a Java property and create Lucene fields in a document. As long as there is a one property for one field relationship, you are good. It becomes more subtle if your custom bridge stores the property in several Lucene fields. Say an Amount type which has the numeric part and the currency part.

Let’s take a real example from a user using Infinispan's search engine - proudly served by Hibernate Search.

The FieldBridge
public class JodaTimeSplitBridge implements TwoWayFieldBridge {

     * Set year, month and day in separate fields
    public void set(String name, Object value, Document document, LuceneOptions luceneoptions) {
        DateTime datetime = (DateTime) value;
            name+".year", String.valueOf(datetime.getYear()), document
            name+".month", String.format("%02d", datetime.getMonthOfYear()), document
            name+".day", String.format("%02d", datetime.getDayOfMonth()), document

    public Object get(String name, Document document) {
        IndexableField fieldyear = document.getField(name+".year");
        IndexableField fieldmonth = document.getField(name+".month");
        IndexableField fieldday = document.getField(name+".day");
        String strdate = fieldday.stringValue()+"/"+fieldmonth.stringValue()+"/"+fieldyear.stringValue();
        DateTime value = DateTime.parse(strdate, DateTimeFormat.forPattern("dd/MM/yyyy"));
        return String.valueOf(value);

    public String objectToString(Object date) {
        DateTime datetime = (DateTime) date;
        int year = datetime.getYear();
        int month = datetime.getMonthOfYear();
        int day = datetime.getDayOfMonth();
        String value = String.format("%02d",day)+"/"+String.format("%02d",month)+"/"+String.valueOf(year);
        return String.valueOf(value);
The entity using the bridge
class BlogEntry {

    @Field(store=Store.YES, index=Index.YES)
    DateTime creationdate;

Let’s query this field

A naive but intuitive query looks like this.

Incorrect query
QueryBuilder qb = sm.buildQueryBuilderForClass(BlogEntry.class).get();
Query q = qb.keyword().onField("creationdate").matching(new DateTime()).createQuery();
CacheQuery cq = sm.getQuery(q, BlogEntry.class);

Unfortunately that query will always return 0 result. Can you spot the problem?

It turns out that Hibernate Search does not know about these subfields creationdate.year, creationdate.month and A FieldBridge is a bit of a blackbox for the Hibernate Search query DSL, so it assumes that you index the data in the field name provided by the name parameter (creationdate in this example).

We have plans in a not so future version of Hibernate Search to address that problem. It will only require you to provide a bit of metadata when you write such advanced custom field bridge. But that’s the future, so what to do now?

Use a single field

I am cheating here but as much as you can, try and keep the one property = one field mapping. Life will be much simpler to you. In this specific JodaTime type example, this is extremely easy. Use the custom bridge but instead of creating three fields (for year, month, day), keep it as a single field in the form of yyyymmdd.

Let’s again use our user real life solution.

A bridge using one field
public class JodaTimeSingleFieldBridge implements TwoWayFieldBridge {

     * Store the data in a single field in yyymmdd format
    public void set(String name, Object value, Document document, LuceneOptions luceneoptions) {
        DateTime datetime = (DateTime) value;
            name, datetime.toString(DateTimeFormat.forPattern("yyyyMMdd")), document

    public Object get(String name, Document document) {
        IndexableField strdate = document.getField(name);
        return DateTime.parse(strdate.stringValue(), DateTimeFormat.forPattern("yyyyMMdd"));

    public String objectToString(Object date) {
        DateTime datetime = (DateTime) date;
        return datetime.toString(DateTimeFormat.forPattern("yyyyMMdd"));

In this case, it would even be better to use a Lucene numeric format field. They are more compact and more efficient at range queries. Use luceneOptions.addNumericFieldToDocument( name, numericDate, document );.

The query above will work as expected now.

But my type must have multiple fields!

OK, OK. I won’t avoid the question. The solution is to disable the Hibernate Query DSL magic and target the fields directly.

Let’s see how to do it based on the first FieldBridge implementation.

Query targeting multiple fields
int year = datetime.getYear();
int month = datetime.getMonthOfYear();
int day = datetime.getDayOfMonth();

QueryBuilder qb = sm.buildQueryBuilderForClass(BlogEntry.class).get();
Query q = qb.bool()
    .must( qb.keyword().onField("creationdate.year").ignoreFieldBridge().ignoreAnalyzer()
                .matching(year).createQuery() )
    .must( qb.keyword().onField("creationdate.month").ignoreFieldBridge().ignoreAnalyzer()
                .matching(month).createQuery() )
    .must( qb.keyword().onField("").ignoreFieldBridge().ignoreAnalyzer()
                .matching(day).createQuery() )

CacheQuery cq = sm.getQuery(q, BlogEntry.class);

The key is to:

  • target directly each field,

  • disable the field bridge conversion for the query,

  • and it’s probably a good idea to disable the analyzer.

It’s a rather advanced topic and the query DSL will do the right thing most of the time. No need to panic just yet.

But in case you hit a complex type needs, it’s interesting to understand what is going on underneath.

IntelliJ IDEA, Mac OS X and Hibernate ORM

Posted by Emmanuel Bernard    |       |    Tagged as Hibernate ORM

Hibernate ORM, IntelliJ IDEA and Mac OS X have been a pretty tough combination to work with since our move to Gradle. It’s not exactly anyone’s fault but the combination of

  • gradle / IntelliJ integration

  • JDK 6 running IntelliJ IDEA

  • Hibernate ORM advanced use of Gradle and of custom plugins

made for a long and painful journey.

These days are over. Steve found the last blocking issue and you can now import Hibernate ORM natively in IntelliJ IDEA.

Importing Hibernate ORM in IntelliJ IDEA on Mac OS X

git clone
  • Open IntelliJ IDEA

  • File → Open

  • Select hibernate-orm

  • The defaults should be good

    • Make especially sure that you select Use default gradle wrapper

    • I use Gradle JVM to 1.8

  • Click OK and let it work and download the internet

You now have a properly imported Hibernate ORM project :)

This worked on Mac OS X 10.10.4 and IntelliJ IDEA CE 14.1.4.

Importing Hibernate ORM in NetBeans on Mac OS X

And this incidentally fixed an import bug for NetBeans.

  • Open NetBeans

  • Install the Gradle plugin

  • Open project

  • Select hibernate-orm

This worked on Mac OS X 10.10.4 and NetBeans 8.0.2.

Hibernate Search, JMS and transactions

Posted by Emmanuel Bernard    |       |    Tagged as Hibernate Search

Hibernate Search sends the indexing requests in the post transaction phase. Until now. The JMS backend can now send its indexing requests transactionally with the database changes. Why is that useful? Read on.

A bit of context

When you change indexed entities, Hibernate Search collects these changes during the database transaction. It then waits for the transaction to be successful before pushing them to the backend.

Hibernate Search has a few backends:

  • lucene: this one uses Lucene to index the entities

  • JMS: this one sends a JMS message with the list of index changes. This JMS queue is then read by a master which uses the Lucene backend.

  • and a few more that are not interesting here

Running the backend after the transaction (in the afterTransaction phase to be specific) is generally what you want. Just to name a few reasons:

  • you don’t want index changes to be executed if you end up rollbacking the database transaction

  • you don’t necessarily want your database changes to fail because the indexing fails: you can always rebuild the index from your database.

  • and most backends don’t support transactions anyways

Hibernate Search lets you enlist an error callback so that you are notified of these indexing problems when they happen and react the way you want (log, raise an exception, retry etc).

So why make the JMS backend join the transaction

If you make the JMS backend join the transaction, then either the database changes happen and the JMS messages are received by the queue, or nothing happens (no database change and no JMS message).

The non transactional approach is still our recommended approach. But there are a few reasons why you want to go transactional.

No code to handle the message failure

It eliminates the need to write an error callback and handle this problematic case.

Simpler exploitation processes

It simplifies your exploitation processes. You can focus on monitoring your JMS queue (rates of messages coming in, rates of messages coming out) which will give you an accurate status of the health of Hibernate Search’s work.

Transactional mass indexing

When doing changes to lots of indexed entities, it is common to use the following pseudo pattern to avoiod OutOfMemoryException

for (int i = 0 ; i < workLoadSize ; i++) {
    // do changes
    if ( i % 500 == 0 ) {

If you use the transactional JMS backend, then all the message will be sent or none of them.

Make sure your JMS implementation and your JTA transaction manager are smart and don’t keep the messages in memory or you might face an OutOfMemoryException.

More consistent batching frameworks flow

If you use a batching framework like Spring Batch which keeps its "done" status in a database, you have a guarantee that changes, indexing requests and batch status are all consistent.

How to use the feature

This feature is now integrated in master and will be in an Hibernate Search release any time soon.

We kept the configuration as simple as possible. Simply add the following property

If you try and use this option on a non transactional backend (i.e. not JMS), Hibernate Search will yell at you.

Make sure to use a XA JMS queue and that your database supports XA as we are talking about coordinated transactional systems.

Many thanks to Yoann, one of our customers, who helped us refine the why and how of that feature.

Sanne is going to do a virtual JBoss User Group session Tuesday July 14th at 6PM BST / 5PM UTC / 1PM EDT / 10 AM PDT. He is going to talk about Lucene in Java EE.

He will also describe some projects dear to our heart. If you want to know what Hibernate Search, Infinispan bring to the Lucene table and how they use Lucene internally, that’s the event to be in!

Apache Lucene is the de-facto standard open source library for Java developers to implement full-text-search capabilities.

While it’s thriving in its field, it is rarely mentioned in the scope of Java EE development.

In this talk we will see for which features many developers love Lucene, make some concrete examples of common problems it elegantly solves, and see some best practices about using it in a Java EE stack.

Finally we’ll see how some popular OSS projects such as Hibernate ORM (JPA provider), WildFly (Java EE runtime) and Infinispan (in-memory datagrid, JCache implementor) actually provide great Lucene integration capabilities.

If you are interested, get some more info on Meetup and enlist.

Multitenancy and current session

Posted by Emmanuel Bernard    |       |    Tagged as Hibernate ORM

Today let’s discuss the interaction between multitenancy and the current session feature.

Multitenancy let’s you isolate Session operations between different tenants. This is useful to create a single application isolating different customers from one another.

The current session feature returns the same session for a given context, typically a (JTA) transaction. This facilitates the one session per view/transaction/conversation pattern and avoids the one session per operation anti-pattern.

Session session = sessionFactory.getCurrentSession();
// do some other work
// later in the same context (e.g. JTA Transaction)
Session session2 = sessionFactory.getCurrentSession();

// semantically we have
assert session == session2

The two features work well together, simply implement CurrentTenantIdentifierResolver. That will give Hibernate ORM the expected tenant id when the current session is created.

How current is current?

When discussing with Florian and the ToulouseJUG, we exchanged on a small case where things might not work as you expect. Hibernate ORM considers that, for a given context (e.g. transaction), there can only be a single current Session.

So if in the same context (e.g. transaction):

  • your CurrentTenantIdentifierResolver implementation returns different values of tenant id,

  • you use getCurrentSession()

you will get a TenantIdentifierMismatchException.

However, it is sometimes useful to be able to reach several tenants from the same context. You have two options:

  • Manually create the Session

  • Implement a custom CurrentSessionContext

Manually create the Session

You can use the SessionFactory API to create a Session for the tenant id you are looking for.

Session session1 = sessionFactory.withOptions()
        .tenantIdentifier( tenant1 )
Session session2 = sessionFactory.withOptions()
        .tenantIdentifier( tenant2 )

But you have to make sure to close these sessions. If you are used to CDI or Spring handling sessions for you, or if you rely on the current session feature to propagate the session across your stack, this might be annoying.

Implement a custom CurrentSessionContext

The alternative is to implement your own version of CurrentSessionContext, avoid raising the TenantIdentifierMismatchException, and keep Session instances per both context and tenant id.

In practice, current sessions are stored in a ConcurrentHashMap keyed by context identifier, you just need to improve that part. Start with JTASessionContext and hack away!

What now?

We are currently discussing whether the default CurrentSessionContext implementations should partition by tenant id or raise the exception. If you have your opinion, chime in!

In the mean time, use one of the options above.

Revamped blog

Posted by Emmanuel Bernard    |       |    Tagged as Discussions

Welcome to the newly revamped Hibernate and friends blog.

As you can see, we made it look like and we took the opportunity to clean up the tags to make them more useful. But we had other reasons to migrate.

Blog early, blog often

We have been very happy with the Asciidoctor-based writing experience of both our reference documentation and of We are bringing this ease of writing to our blog and the not so secret objective is for us to blog more. So if you don’t see more content here, you can start yelling at us :)

Write once, display anywhere

There is an added bonus to using Asciidoctor for all of our writing: we can move content easily between systems. What starts as a blog can easily become a how-to page on the site or a section in the reference documentation.


We had a few issues with the old infrastructure that were keeping us away from our IDEs a bit too often for comfort.
This blog is a statically generated site, we use Awestruct. This means that we can make is scale very easily and with very low maintenance. Nothing beats plain old HTML :)

We did migrate all the old entries and comments from the old blog: fear not, nothing is lost.

If you seen any issue, let us know in the comments or by tweet. Oh and enlist to our new feed URL.

Célébrons l'open source et le partage (English version below).

Place pour Devoxx France à gagner

Devoxx France vous offre une place: je ne suis que le messager :) Elle sera gagnée par l'un d'entre vous. La règle est simple.

Contribuer à un projet open source (code, doc, etc) entre maintenant et dimanche 29 mars 2015 et tweeter le lien vers la pull request ou le patch à @Hibernate.

  • Quel projet ? N'importe pourvu que la licence soit open source. Donc pas limité à Hibernate.
  • Comment sera choisi le vainqueur ? La contribution que je préfère sera choisie. Super bonus si c'est votre première contribution à ce projet : il faut que ça brasse :)
  • Mais si on contribue à un projet Red Hat, on a plus de chance ? Non, tous les projets open source sont (libres et) égaux.
  • Je suis employé Red Hat, je peux gagner? Non. Contacte-moi directement.
  • Et ? C'est tout.

Devoxx France se déroule du 8 au 10 avril à Paris (Palais des Congrès). J'y parlerai entre autre des sujets Object Mappers dans le NoSQL et une BoF Hibernate.

Aller au boulot !

Free pass for Devoxx France

Devoxx France is giving away a free pass through me. I am just the messenger :) One of you will win it. The rule is simple.

Contribute to an open source project (code, doc, etc) between now and Sunday evening 29th of March 2015 and tweet the link to the pull request or the patch to @Hibernate.

  • Which project? Any project released under an open source license. Not limited to Hibernate.
  • How will you chose the winner? The contribution I prefer will be chosen. Extra bonus if that's your first contribution on that project: let's exchange!
  • But if I contribute to a Red Hat project, I have a better chance? No, all open source projects are equals.
  • I am a Red Hat employee, can I win? No. Contact me directly instead.

Devoxx France happens in Paris from the 8th to the 10th of April. I will be speaking about a few topics including Object Mappers and NoSQL and an Hibernate BoF.

Now go contribute!

PS légal: cette place est offerte par Devoxx France et Emmanuel Bernard à titre personnel, pas par Red Hat. Bref, je fais ce que je veux, avec mes cheveux. Legal PS: this pass if given away by Devoxx France and Emmanuel Bernard as an individual and free human being, not Red Hat.

First Hibernate OGM release (aka 4.1 Final)

Posted by Emmanuel Bernard    |       |    Tagged as Hibernate OGM Releases

Today is a big day. The first release of Hibernate OGM with final status. Ever! Don't be fooled by the 4.1 number. Hibernate OGM is an object mapper for various NoSQL stores and offers the familiar JPA APIs. This final version offers mapping for MongoDB, Neo4J, Infinispan and Ehcache.

It has been a long journey to reach this release, much longer than we thought. And there is a long journey ahead of us to implement our full (and exciting!) vision. But today is the time to celebrate: download this puppy and try it out.

What is Hibernate OGM?

Hibernate OGM is an object mapper. It persists object graphs into your NoSQL datastore.

We took great care to map the object structures the most natural way possible ; we considered all the best practices for each of the NoSQL store we support. Storing a association in a document store is vastly different than storing the same association in a graph database.

// Unidirectional one to many association

// Basket
  "_id" : "davide_basket",
  "owner" : "Davide",
  "products" : [ "Beer", "Pretzel" ]

// Products
  "_id" : "Pretzel",
  "description" : "Glutino Pretzel Sticks"
  "_id" : "Beer",
  "description" : "Tactical nuclear penguin"

Hibernate OGM is 90% Hibernate ORM. We changed the parts that are specific to SQL and JDBC, but most of the engine remains untouched. Same power, same flexibility.

What is the API like?

Very simple. It's JPA. Or Hibernate ORM. Map your entities with JPA annotations (or via XML), then use JPA or the Hibernate native APIs to manipulate your objects.

@PersistenceContext EntityManager em;

// the transaction boundary is really here to express the flush time
public void createSomeUser() {
    Employer redHat =
        em.createQuery("from Employer e where = :name")
        .setParamater("name", "Red Hat")
    User emmanuel = new User("Emmanuel", "Bernard");

Our goal is to have a zero barrier of entry to NoSQL object mappers for people familiar with JPA or Hibernate ORM.

Hibernate OGM also has a flexible option system that lets you customize some of the NoSQL store specifics or mapping options. For example what is the MongoDB Write Concern for this entity (see code example) or should associations be stored in the owning entity document.

@WriteConcern(JOURNALED) // MongoDB write concern
public class User {

And queries?

We cannot talk about JPA without mentioning JP-QL. Offering JP-QL support is challenging at many levels. To mention only two, joins usually don't exist in NoSQL, and each store has a very different set of query capabilities.

Hibernate OGM can convert JP-QL queries to the underlying native query language of the datastore. This functionality is still limited however. Besides some queries will never map to JP-QL. So we also let you write native queries specific to your NoSQL store and map the results to managed entities.

// native query using CypherQL
String query = "MATCH ( n:Poem { name:'Portia', author:'Oscar Wilde' } ) RETURN n";
Poem poem = (Poem) em.createNativeQuery( query, Poem.class ).getSingleResult();

Where can I use Hibernate OGM?

It works anywhere Hibernate ORM or any JPA provider works. Java SE, Java EE, all should be good. We do require JPA 2.1 though. If you use WildFly (8.2), we have a dedicated module to make things even easier.

For which NoSQL store?

MongoDB, Neo4J, Infinispan and Ehcache are the one we consider stable. We are working on CouchDB and Cassandra. But really, any motivated person can try and map other NoSQL stores: that's how a few got started. We have an API that has proven flexible enough so far.

Can Hibernate OGM do X, Y, Z?

Probably. Maybe not.

The best is to talk to us in our forums, check our documentation (we spent a lot of time on it), and simply give it a try.

Generally, the mapping support is complete. Our query support is still a bit limited compared to where we want it to be. It will improve quickly now that the foundations are here.

We want to know what you need out of Hibernate OGM, what feature you miss, which one should be changed. Come and talk to us in our forum or anywhere you can find us.

How to get started?

Most of what you need is available in our web site. There is a getting started guide, and the more complete reference documentation. Get the full Hibernate OGM distribution. And last but not least, for any help, reach us via our forum.

It would be impossible to mention all the persons that contributed to Hibernate OGM and how: conversations, support, code, documentation, bootstrapping new datastore providers... Many thanks to all of you for making this a reality.

We are not done yet, far from it. We have plenty of ideas on where we want to bring Hibernate OGM. That's a discussion for another day.

back to top