Using Log4J2 with Hibernate 4

I was trying to use Hibernate 4.3.8.Final with Log4J2 and I spent some hours to find why Hibernate was not using Log4J2 though it was declared in my pom.xml file.

Actually, I hit this issue JBLOGGING-107.

The workaround is simply to add a more recent jboss-logging dependency than the one shipped by default with Hibernate 4.3.8.Final.


Once upon a time: Make your dreams come true

Oh wait! Already 2 years spent working for Elasticsearch? Time flies!

After the first year, I wrote that I did 58 talks in 4 countries, 37 towns for about 18 000 kilometerstraveled. I was pretty sure that things would continue to grow.

This year, I spoke 78 times! Around 2 talks per week! I did around 48 000 kilometers. 8 000 km more than the earth’s circumference! I still can’t believe it… 12 countries. And no need to say that I love giving talks and sharing my enthusiasm about Elasticsearch!

I think that I’ll put all this data together in Elasticsearch in the coming year, then create a Kibana dashboard to have a better overview of the talks I’m giving. :)

« Eat your own dog food » is something Shay often says….

What did I do this year?

There are always a lot of nice folks to meet at each event: speakers, organizers and attendees. I come away from these events with a lot of good vibes and energy.

The French community grew a lot as well this year and we have now the fantastic Livia on board to organize all the things. So if you want to give a talk to the French speaking community, please contact her!

From a 10 person company to more than 100

Elasticsearch clusters scale horizontally very well. Documents are distributed within the cluster. I feel the company functions this same way. We are a distributed team, all around the world and we are adding more and more brain power to our company. And what additions! We are building a very strong team in every single field in the organization. The hard part now is to recall everyone’s name or job function! I guess I’ll need to add more memory to my own brain really soonish! :)

A lot of babies were born last year, and new ones are coming in 2015. That’s super great. We love families and babies at Elasticsearch! We can always find a good balance between our personal life and job duties. That’s an important part of our company spirit.

As I wrote last year, building company core values is not hard at Elasticsearch, as we talk to each other on a daily basis and all hands company meetups happen every 6 months or so. But for the last one, in Amsterdam, it was hard to fit everyone in the same room!

So? What is the solution? Let’s create a user conference and bring all the folks there! Welcome to elastic{ON}!

I am super excited going to San Francisco in March, meeting up again with all the colleagues I already know and seeing all the new comers in real life. And meeting… Users! I love users! They are contributing back so much to our open source projects by submitting code, documentation, issues or simply talking about their use cases at meetups!

By the way, if you are a meetup organizer, you must see our dedicated meetup page!

We will give an update on the State of the Community from all of our Developer Advocates at elastic{ON}, so if you are around, come and meet us!

What’s new? What’s next?

It’s not new, but we’re hiring! Want to join us? Have a look at our open positions here. Feel free to ask me any questions about these roles and what its like to work at the company!

Great improvements came to the codebase this year. Elasticsearch is now 1.4.2, Logstash 1.5.0.Beta1 and Kibana 4 is in Beta. Some commercial plugins has been released or announced, such as Marvel for cluster monitoring and Shield which is all about security. It’s great seeing so many people involved on those projects. I think that we probably invest 80 to 90% of our development efforts today on open source projects.

Of course, when you start to release commercial products, you always getting some feedback, such as: « Hey, it must be free! ». We actually don’t have a specific Elasticsearch, Logstash or Kibana version for customers and a community version – our stack is the same for all using it. And that’s something really important in my opinion. It means that people can create plugins on top of Elasticsearch & the ELK stack and provide same services to their users.

We are actively working on Elasticsearch 2.0 (ie. New Aggregation Types, Resiliency), Logstash 1.5 GA (Performance, Kafka, Migrating from Rivers to Logstash input plugins) and 2.0 (Persistence, Clustering, Performance) and Kibana 4.0 which is already available as a Beta. Plus our work on clients, plugins and other ecosystem tools. We have also an infrastructure team who are busy behind the scenes providing services like continous integration, which helps a lot to uncover issues! Our support team gives the best support you have ever dreamed of, and we developers continue to work really closely with this team.

From startup to success…

I can remember the day I started to speak with Shay, then with Clint, Uri and Steven about working at Elasticsearch. I never regretted taking the « risk » of joining a startup.

We are already a succesful company. So many customers are paying for our support subscriptions, such as PayPal, Facebook, Cisco, Adobe, Swiss Life, Banque de France, Société Générale, Tom Tom and the list goes on….

I can not obviously talk about the details of our financial numbers, but I can tell that we are always above our business plan which is very unusual for a startup.

My only regret is that days have only 24 hours. Not enough time to do all what I’d like to do.

What about you? Are you ready to make your dreams come true?

Once upon a time: an elastic fairy tale!

Once upon a time…

In fact 2 years ago, I was looking for a way to make Hibernate search distributed on multiple nodes. My first idea was to store indexes in a single database shared by my nodes. Yes, it’s a stupid idea in term of performances but I would like to try to build it.

Digging for source code, I came to the JdbcDirectory class from the compass project. And I saw on the compass front page something talking about the future of Compass and Elasticsearch.

The future of compass and Elasticsearch
The future of compass and Elasticsearch

Two clicks later, I discovered Elasticsearch. I downloaded it, started and said “WTF! How can it be?” This project solved all my concerns and adds even features I was not aware of in less than 30 seconds! I did not sleep during one full week, really! That was too much magical! After some hours, Elasticsearch was implemented in my project and was providing the first full text searches. I told to my colleagues that this project is so wonderful that I want to be involved if a company is created.

At this point, I was looking to contribute back to the project. But, I was not an Elasticsearch expert nor a Lucene one. I searched for French web content about it and found one or two articles. So I started to write some French content on my personal blog. I also started to create some plugins. The RSS River was the first one. By the way, that was my first open source project.

I met Shay Banon the first time in June 2011 for a conference in Paris. He was doing a no-slide no-bullshit talk. Very impressive. It just works! I told him that as I can not contribute on the core project, I can try to talk about the project in France. He agreed and the French user group was born!

Elasticsearch French Community
Elasticsearch French Community


One year later, my talk for Devoxx France was accepted and everything really started from here. The French user group grows now each day.

Some months later, the company Elasticsearch BV was created. It was really clear to me that I have to join. When you fall in love, you should marry! I met Shay once again at Devoxx 2012 and we talked about it, about what value I can add to Elasticsearch. And now, two years after the first day I discovered Elasticsearch my dreams comes true, just like in fairy tales!

Il était une fois : un conte de fées élastique !

Il était une fois…

En fait, il y a 2 ans, je cherchais un moyen pour distribuer Hibernate search sur plusieurs noeuds. Ma première idée était de stocker les index dans une base de données partagée par les différents noeuds. Oui ! Il s’agit d’une idée stupide en terme de performances, mais j’avais envie d’essayer et de construire ce modèle.

Après avoir cherché du code source, je suis finalement tombé sur la classe JdbcDirectory du projet Compass. Et sur la page d’accueil du projet, j’aperçois quelque chose qui parle du future de Compass et d’Elasticsearch.

The future of compass and Elasticsearch

Deux clics plus tard, je découvre Elasticsearch. Je le télécharge, le démarre et me dis : « Bordel ! Mais comment est-ce possible ? ». Ce projet venait non seulement de résoudre tous mes problèmes en ajoutant des fonctionnalités dont je n’avais même pas conscience, le tout en moins de 30 secondes ! Je n’ai pas dormi pendant une semaine entière, vraiment ! C’était trop magique pour être vrai ! Après quelques heures de travail, Elasticsearch était intégré dans mon projet et fournissait déjà les premières recherches full text. J’ai dit à mes collègues que ce projet est si magnifique que je veux en faire parti si un jour une société est créée.

A partir de ce moment, j’ai cherché comment contribuer en retour sur le projet. Mais, je n’étais ni un expert Elasticsearch, ni même un expert Lucene. J’ai alors cherché du contenu français parlant du projet et je n’ai trouvé qu’un ou deux articles. J’ai commencé alors à écrire du contenu sur mon blog personnel. J’ai également commencé à écrire quelques plugins. La rivière RSS fut la première. Elle fut d’ailleurs mon premier projet open-source.

J’ai rencontré Shay Banon la première fois en Juin 2011 pour une conférence donnée à Paris. Il donnait un talk sans slides comme il sait les faire. Très impressionnant ! It just works ! Je lui ai alors dit que comme je ne pouvais pas directement contribuer au coeur du projet, je pouvais essayer de promouvoir le projet en France. Il a immédiatement accepté. La communauté française était née !

Elasticsearch French Community


Une année plus tard, mon talk pour Devoxx France était accepté et tout allait vraiment démarrer à partir de là. Le groupe français n’a pas cessé de grossir depuis, de jour en jour.

Quelques mois plus tard, la société Elasticsearch BV était créée. Il était vraiment clair dans mon esprit que je devais les rejoindre. Quand vous tombez amoureux, vous devez vous marier ! J’ai rencontré à nouveau Shay à Devoxx 2012 et nous en avons parlé, notamment de ce que je pourrais apporter à Elasticsearch. Et maintenant, deux ans après ma première rencontre avec Elasticsearch, mon rêve devient réalité, comme dans les contes de fées !

ScrutMyDocs : un moteur de recherche pour documents

Technical overview

Avec Malloum, nous venons de publier notre premier projet open-source commun: Scrut My Docs !

Nos objectifs

  • Fournir une application web clé en main permettant d’indexer des documents de vos disques locaux.
  • Fournir à la communauté Elasticsearch un modèle de base pour développer votre propre webapp pour une utilisation simple de recherche (« à la google »).
  • Aider les débutants Elasticsearch Java avec des exemples concrets en Java

Les technologies employées

  • Elasticsearch ! et son écosystème (rivers, plugins)
  • Spring
  • JSF
  • Primefaces

Comment démarrer ?

Télécharger la webapp et la déployer dans votre conteneur favori (testé sur Tomcat et Jetty).

La documentation est sur la repository GitHub

Plus de détails et une démo sur le site web :

Les commentaires sur le projet, les demandes d’évolution, les rapports de bug et les pull requests sont évidemment les bienvenus !

Protéger son cluster Elasticsearch avec Jetty

Nativement, Elasticsearch expose l’ensemble de ses services sans aucune authentification et donc une commande du type curl -XDELETE http://localhost:9200/myindex peut faire de nombreux dégâts non désirés.

De plus, si vous développez une application JQuery avec un accès direct depuis le poste client à votre cluster Elasticsearch, le risque qu’un utilisateur joue un peu avec votre cluster est grand !

Alors, pas de panique… La société Sonian Inc. a open sourcé son plugin Jetty pour Elasticsearch pour notre plus grand bonheur ;-)


Le principe consiste à rajouter une surcouche Jetty à Elasticsearch, sous forme de plugin.

Il ne reste plus qu’à restreindre certaines URL et certaines méthodes (DELETE par exemple) à certains utilisateurs.

Guide d’installation

Pour installer le plugin, connectez vous à votre serveur hébergeant Elasticsearch et allez dans le répertoire d’installation :

Installez le plugin (vérifiez la compatibilité entre la version du plugin et celle de votre noeud) :

Récupérez le fichier de configuration de jetty proposé par Sonian en exemple :
Idem pour le fichier avec les logins / password :

Il faut ensuite modifier la configuration Elasticsearch et ajouter la ligne suivante dans config/elasticsearch.yml :

Les petits gars de Sonian ayant très bien fait leur boulot, les protections nécessaires sont déjà en place avec le fichier config/jetty.xml très complet.

Modifiez les valeurs par défaut de login/password dans config/ :

Redémarrez Elasticsearch. Si vous l’avez installé en tant que service :

Et voilà ! Impossible de faire des commandes du type :

Mais avec authentification, ça passe :

Une factory Spring pour Elasticsearch

Le besoin

Il existe dans Hibernate une fonctionnalité que j’aime beaucoup : la mise à jour automatique du schéma de la base en fonction des entités manipulées.

Mon besoin est de faire quasiment la même chose avec Elasticsearch. C’est à dire que je souhaite pouvoir appliquer un mapping pour un type donné à chaque fois que je démarre mon projet (en l’occurrence une webapp).

En me basant sur le projet développé par Erez Mazor, j’ai donc développé une factory Spring visant à démarrer des clients (voire des noeuds) Elasticsearch.

La solution

Donc, on se place dans un environnement de développement Java, Maven et Spring.

Pour importer la factory, il suffit d’ajouter ces quelques lignes à votre pom.xml.


Il suffit ensuite de définir son bean client Elasticsearch ainsi :

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""

<elasticsearch:client id="esClient" />


Par défaut, on obtient ainsi un TransportClient qui se connecte automatiquement au noeud Elasticsearch tournant à l’adresse http://localhost:9200/.

L’intérêt de cette factory est donc de pouvoir prédéfinir ses index et ses types au moment où elle démarre. Ainsi, si vous avez un index nommé twitter et un type nommé tweet, vous pouvez en définir les propriétés respectives en plaçant simplement dans votre classpath un fichier es/twitter/_settings.json et un fichier es/twitter/tweet.json. Le premier sera appliqué au moment de la création de l’index. Le deuxième sera appliqué au moment de la création du type.

Pour cela, il faut, comme pour Hibernate, définir les types gérés :

<bean id="esClient" class="fr.pilato.spring.elasticsearch.ElasticsearchClientFactoryBean" >
<property name="mappings">

La factory permet également de gérer la création automatique d’alias sur des index. Pour cela, on utilise la syntaxe suivante.

<bean id="esClient" class="fr.pilato.spring.elasticsearch.ElasticsearchClientFactoryBean" >
<property name="aliases">

Ainsi, au démarrage, les index twitter2012, twitter2013 et twitter2014 auront un alias twitter.

D’autres fonctionnalités sont possibles. Voir le README disponible sur github.

J’utilise déjà ces premières fonctionnalités en production sur un de mes projets au boulot.

Dernière petite fonction mais à manier avec précaution car elle est plutôt destinée à faire de l’intégration continue. Il s’agit du paramètre forceReinit qui reconstruit à chaque démarrage les types gérés. Aussi, toutes les données de ces types sont perdues à chaque lancement de la factory.

Mon talk sur Elasticsearch sélectionné pour Devoxx France


C’est avec une certaine émotion et fierté que j’ai appris samedi dernier la sélection de mon talk sur Elasticsearch à Devoxx France.

Devoxx France est une conférence organisée du 18 au 20 avril 2012 à Paris, pour les Développeurs. Y faire parti au milieu de talents incroyables est vraiment un honneur.

Je suis d’autant plus comblé que je vais pouvoir parler du sujet qui me passionne depuis maintenant 1 an : Elasticsearch.

A l’origine, Shay Banon devait venir lui-même nous parler de l’analyse des données avec les facettes Elasticsearch, mais il ne pourra malheureusement pas être présent.

  • Le moins : vous n’avez pas en face de vous le BIG BOSS ! :-(
  • Le plus : la conférence est en français ;-)

Mon objectif pour ce talk est de vous faire partager mon enthousiasme pour ce projet magnifique, de faire décoller la communauté française @ElasticsearchFR et de susciter des engouements à utiliser, forker et contribuer !


Je vais principalement présenter les fonctionnalités d’Elasticsearch que j’utilise tous les jours, parler un peu architecture, insister sur la partie facette (navigation par facettes) et faire quelques démos live… Je vais d’ailleurs avoir besoin de votre concours pour faire un « maximum de bruit » sur Twitter pendant la conf !

Pour le moment, le slot de la conférence est le jeudi 19 avril à partir de 11H30.

Réservez votre journée ! Venez nombreux !

Quel client Java pour ElasticSearch ?

Il existe deux modes d’accès à Elasticsearch :

  • Inscrire un noeud client dans le cluster ElasticSearch
  • Utiliser un client « simple »

Noeud client dans un cluster Elasticsearch

L’idée de cette méthode est de fabriquer un noeud Elasticsearch (node) qui démarre avec les mêmes caractéristiques qu’un noeud d’indexation et de recherche sauf qu’on lui précise qu’il n’hébergera pas de données.

Pour cela, on utilise la propriété suivante :

Elle indique que le noeud que nous démarrons n’hébergera pas de données. En gros, c’est un noeud qui sert juste à fabriquer des clients…

L’avantage est qu’il n’est pas nécessaire de configurer quoi que ce soit car la particularité des noeuds Elasticsearch est de s’auto-découvrir les uns les autres grâce aux fonctions de multicast.

Démarrer un noeud autonome est également intéressant pour réaliser des tests unitaires. En effet, dans ce cas, vous avez une instance autonome complète d’Elasticsearch.

Démarrer un noeud et obtenir un client, ce n’est pas bien difficile :

// Build a node
Node node = NodeBuilder.nodeBuilder().node();

// Get a client from the node
Client client = node.client();

Avec la première ligne, vous devriez voir apparaître dans les logs de vos noeuds Elasticsearch, le fait qu’un nouveau noeud a rejoint le cluster.

Client « simple » ou TransportClient

Un Transport Client est un client Elasticsearch autonome plus léger qui n’appartient pas réellement au cluster de noeuds Elasticsearch. Ainsi, lorsqu’un client démarre, aucune trace n’apparaît dans les logs des noeuds du cluster puisque ce client ne fait pas proprement parti du cluster.

Pour qu’un tel client sache comment trouver des noeuds Elasticsearch du cluster que vous souhaitez rejoindre, il faut lui indiquer au moins une adresse. Vous pouvez préciser plusieurs adresses pour mieux gérer les pannes et la répartition de charge.

Pour démarrer un tel client, on écrit donc :

TransportClient client = new TransportClient()
.addTransportAddress(new InetSocketTransportAddress("localhost", 9300))
.addTransportAddress(new InetSocketTransportAddress("localhost", 9301));

Quel client choisir ?

Passer par un noeud pour obtenir un client peut perturber votre cluster, même si en théorie, ça devrait être neutre. Car le noeud fait partie du cluster. Donc, quand il meurt, les autres noeuds doivent être prévenus pour prendre des décisions. En l’occurrence, aucune décision à prendre car le noeud n’héberge pas de données. Mais cela nécessite un traitement même minime de la part des noeuds.

De la même façon quand un noeud arrive dans le cluster, il se déclare, occupe deux ports de communication (9200-9299 et 9300-9399) car en tant que noeud il peut être amené à recevoir des requêtes.

De plus, un noeud ElasticSearch démarre plus de Threads et notamment un qui pose problème en ce moment en raison d’un souci avec la librairie Guava. En mode debug sous Eclipse par exemple, cela va vous empêcher de redémarrer proprement votre webapp sans avoir à redémarrer le serveur d’application.

En production, c’est pareil. Si vous embarquez dans votre webapp un noeud client Elasticsearch, vous devrez obligatoirement redémarrer le serveur d’application sous peine d’erreur de mémoire (OOM).

Donc, mon expérience m’indique qu’il vaut mieux passer par des clients plus légers et neutres pour le cluster. J’ai donc choisi dans mes projets la deuxième option lorsque j’ai besoin d’un client dans une webapp.

Lorsque je veux faire des tests unitaires (ou d’intégration) de mon application, j’utilise plutôt la première méthode.

Et il y a un moyen de choisir quand je veux ce que je veux ?

Dans un prochain article, je vous décrirai la factory Spring que j’ai développée et publiée sur github.

La version n’est pas encore finalisée, notamment en raison d’un petit bug avec la version 0.19.0.RC2 d’Elasticsearch, mais la version SNAPSHOT est en cours de tests dans un de mes projets.