Publié par

Il y a 8 ans -

Temps de lecture 6 minutes

Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Actualité éditeurs / SSII

Evénements de notre communauté en France et à l’étranger

Actualité éditeurs / SSII

Valider vos méthodes avec Hibernate Validator 4.2.0

Pour rappel, comme nous l’avions déjà évoqué ici, Hibernate Validator permet de faire de la validation de bean suivant la JSR-303 – Bean Validation. Cette JSR propose de standardiser les mécanismes de validation qu’un développeur est souvent amené à faire à la main en utilisant entre autre des annotations ou alternativement des fichiers xml. Cette normalisation a l’avantage d’uniformiser au sein d’une même application les couches de présentation (des frameworks de présentation comme Wicket par exemple propose leur solution), les couches de service ou de persistence avec les mêmes outils.

A titre d’exemple:

public Person {
	@NotNull
	private String name;

	@Past
	private Date birthday;
}

@Past contraint que la date soit dans le passé.

Hibernate Validator est la version d’implémentation de cette JSR et contrairement à ce qu’on pourrait croire n’impose pas d’utiliser Hibernate. D’ailleurs JBoss/Hibernate propose un TCK pour les développeurs désireux de valider leur validateur.

La grande nouveauté de cette version est la possibilité de faire de la validation au niveau de la méthode:

public @NotNull String saveItem(@Valid @NotNull Item item, @Max(23) BigDecimal price)

Comme on peut remarquer, il est à présent possible de valider les paramètres ainsi que la valeur de retour d’une méthode. Pour valider cette méthode il faut ensuite créer un validateur:

MethodValidator validator = Validation.byProvider( HibernateValidator.class )
    .configure()
    .buildValidatorFactory()
    .getValidator()
    .unwrap( MethodValidator.class );

Et ensuite utiliser une des méthodes du validateur:

public interface MethodValidator {
    public <T> Set<MethodConstraintViolation<T>> validateParameter(T object, Method method, Object parameterValue, int parameterIndex, Class<?>... groups);
    public <T> Set<MethodConstraintViolation<T>> validateParameters(T object, Method method, Object[] parameterValues, Class<?>... groups);
    public <T> Set<MethodConstraintViolation<T>> validateReturnValue(T object, Method method, Object returnValue, Class<?>... groups);
}

On peut trouver le mécanisme un peu rébarbatif si on doit répéter l’opération sur chaque méthode et pour chaque paramètre mais, comme le suggère ce post, on peut facilement l’associer à un aspect pour automatiser ces validations.

Parmi les autres nouveautés on peut également à présent combiner les contraintes autrement que par conjonction et un nouveau mécanisme de templating des exceptions a été ajouté. Les détails de la release se trouvent ici, ici et

Distribuer vos logs avec Kafka 0.6

Comme nous vous l’avions annoncé il y a un peu plus de 6 mois dans la revue de presse, LinkedIn a rendu open source son broker de messages atypique Kafka. A l’occasion de la sortie de la version 0.6 Neha Narkhede, ingénieur chez LinkedIn, nous rappelle les cas d’utilisation principaux de Kafka:

  • Collecter des logs pour les insérer dans Hadoop ou dans un data warehouse pour une analyse offline.
  • Nourrir directement des applications en écoute d’alertes en temps réel (pour la sécurité par exemple).
  • Déployer les données recueillies d’Hadoop vers des applications.

Ces cas d’utilisation ont grandement guidé l’architecture de Kafka qui accentue beaucoup plus la rapidité à envoyer les messages, la garantie de persistence et le clustering au détriment d’une plus grande responsabilisation des consommateurs de messages qui ont en charge l’acknowledgement et la découverte de la topologie des brokers.

Parmi les nouveautés de cette nouvelle version on notera:

  • Ajout d’un load balancing automatique pour les producteurs de messages. En masquant la topologie du cluster, Kafka peut s’appuyer sur un load balancer hardware et utilise zookeeper pour la partie logique.
  • Possibilité d’envoyer de façon asynchrone les messages.
  • Possibilité d’enrichir sémantiquement les partitions afin par exemple de rapprocher les données liées au niveau du métier

Un très bon article des ingénieurs de LinkedIn décrit très bien l’architecture de Kafka dans le cas de la génération de logs et qui contient des comparatifs, à prendre avec beaucoup de précaution, avec ActiveMQ et RabbitMQ. Je vous laisse deviner le grand vainqueur.

Une implémentation NIO du connecteur AJP de Tomcat

Cela aurait pu passer inaperçu car cette fonctionnalité a été ajoutée dans la version mineure de Tomcat 7.0.16, le connecteur AJP implémente à présent l’API New I/O pour gérer ses pools de threads. Un article très pédagogique de Mark Thomas, ingénieur chez SpringSource, met en lumière cette nouvelle fonctionnalité.

Jusqu’à maintenant à un thread sur un serveur Apache HTTPD, par exemple, devait correspondre un thread du côté des serveurs Tomcat. Donc pour 1000 threads sur deux serveurs HTTPD devaient correspondre 2000 threads sur chaque serveur Tomcat branché derrière. On comprend vite la complexité et les limitations engendrées.

Cette nouvelle implémentation permet de gérer plus intelligement ces threads côté Tomcat, à l’aide de quelques threads (l’article recommande pas plus de 10) on peut maintenir un ensemble de connections sans problème.

Un grand pas pour les utilisateurs de ce connecteur, sans oublier qu’il existe également le mod_proxy_http, la comparaison entre les deux étant détaillés dans notre article ici.

Evénements de notre communauté en France et à l’étranger

Un déplacement plein d’enseignements

Cette RDP est l’occasion de faire un petit bilan sur le court déplacement, début juin, de 3 de nos Xebians Parisiens chez nos collègues Néerlandais. L’objectif de ce voyage était triple:

  • Favoriser les échanges d’expériences sur la transition vers l’agilité
  • Passer en revue le modèle de pépinière interne
  • Renforcer les liens entre entités

Jean-Laurent et Gilles ont apporté leur contribution au XKE Néerlandais en présentant chacun un sujet aux membres de la business unit Agile Consulting and Training (ACT), l’un sur l’évolution d’une équipe agile dans la durée, l’autre sur la transformation agile à grande échelle. Pendant ce temps Aurélien a longuement discuté des projets pépinières chez Xebia NL et du modèle de contribution associé. La journée s’est terminée par une présentation de l’ensemble des missions en cours au sein de ACT portant sur la transition des organisations vers l’agilité. Les références de nos voisins sont impressionnantes et nous repartons avec des nouveautés plein la tête.

Si nous ne devions retenir qu’une chose de ce voyage ce serait sans aucun doute la découverte du livre Business Model Generation qui présente un canevas simple et puissant pour discuter et formaliser un business model. Un outil qui nous paraît indispensable pour le Product Owner et son travail de priorisation et valorisation de ses stories.

Nous avons également découvert des obstacles à l’agilité que nous connaissons peu en France, certaines entreprises pratiquent par exemple la politique de bureau libre, ce qui empêche fortement la colocalisation. Nous repartons plus riches de nos différences culturelles quant à la mise en application de SCRUM et des pratiques agiles. Pour un voyage dans la patrie de Gert Hofstede, le fondateur de la théorie des dimensions culturelles, ce n’est peut être pas si étonnant.

Publié par

Publié par Xebia France

Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 15 ans, nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

Commentaire

3 réponses pour " Revue de Presse Xebia "

  1. Publié par , Il y a 8 ans

    Ce qui est intéressant avec les Hibernate Validator c’est de récupérer l’exception afin de pouvoir mettre en rouge le label du champ de formulaire en erreur.

    Avec un peu de convention on peut le faire facilement. Un exemple pour gwt se trouve dans les sources exemple du framework gwtop pour les curieux.

  2. Publié par , Il y a 8 ans

    Bonjour,

    la lecture du § sur Hibernate Validator me hérisse le poil. Aucune critique sur votre article mais sur l’intérêt de la technologie.

    Pourquoi choisissons nous d’utiliser Hibernate ? Pour une solution de persistance de données.
    Quel rapport avec des contraintes appliquées au modèle objet qui peuvent simplement être réalisées en java ? Aucune, si ce n’est créer une dépendance supplémentaire à notre projet.

    Je condamne l’utilisation abusive de dépendances telles que celles que propose l’écosystème JBoss car elles enferment nos projets dans des cadres à la limite du propriétaire, elles vont à l’encontre du principe de parcimonie (faire beaucoup avec peu) et elles compromettent la longévité des travaux en multipliant les connaissances à maitriser pour maintenir les applications.

    Si cette réaction quelque peu épidermique peut faire réagir qq’un, ce ne sera pas peine perdue.

    Merci à la rédaction de Xebia pour ses articles fréquents et instructifs.

  3. Publié par , Il y a 8 ans

    @Jeff: je ne suis pas de votre avis, au contraire,

    1. Les annotations allègent énormément les projets.

    2. Les hibernates validators sont des annotations à ajouter sur le modèle. Utilisant déjà des annotations (pour la raison 1) pour déclarer les Pojo en entite ainsi que la définition des getters / tables, dans ce contexte il n’y a donc pas de dépendances supplémentaires sur la couche du modèle, qui dépend donc déjà d’Hibernate.

    3. Les dépendances liés aux annotations sont moins intrusives que du vrai code. On peut quand même utiliser les Pojos dans des contextes qui ne connaissent pas hibernate. Exemple: la couche cliente de Gwt.

    4. Le meilleur endroit pour appliquer des contraintes au modèle est justement le modèle lui même. Les Hibernates Validators permettent d’alléger nos projets en évitant d’éparpiller ces contraintes un peu partout das le code. Ce dernier point répond à l’une des exigence du Domain-Design Driven.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.