Rappels sur les éléments externes à Spring

Codage equals et hashCode

L’égalité entre objets joue un rôle crucial dans Spring, particulièrement dans les architectures qui utilisent le mapping objet-relationnel (ORM), comme Hibernate et JPA. Dans ces systèmes, les notions de proxy sont fréquentes. Lorsqu’on travaille avec deux objets en mémoire, il est important de faire attention à ne pas confondre un proxy avec l’objet qu’il représente.

Pour éviter ce problème, vous pouvez utiliser instanceof au lieu de getClass() dans votre méthode equals(). instanceof vérifie qu’un objet est une instance d’une classe particulière ou de l’une de ses sous-classes, donc il renverra true même si l’un des objets est un proxy Hibernate.

Voici comment vous pourriez implémenter cela :

@Override 
public boolean equals(Object o) { 
    if (this == o) return true; 
    if (!(o instanceof MyEntity)) return false; 
    MyEntity myEntity = (MyEntity) o; 
    return Objects.equals(businessKey, myEntity.businessKey); 
} 

Dans cet exemple, nous utilisons instanceof pour vérifier que l’objet est une instance de MyEntity ou de l’une de ses sous-classes. Cela permettra à equals() de fonctionner correctement même si l’un des objets est un proxy Hibernate.

Par ailleurs, du point de vue métier, deux objets peuvent être considérés comme identiques même s’ils existent comme instances distinctes en mémoire. Cette distinction est particulièrement importante lorsqu’on travaille avec des collections.

De plus, nous utilisons parfois des clés techniques qui ne sont renseignées qu’au moment de la persistance.

Les méthodes equals et hashCode en Java ont une définition spécifique qui détermine comment les objets doivent être comparés et identifiés. Dans le contexte de Spring, Hibernate et JPA, où les proxies et les listes sont largement utilisés, il est nécessaire d’adapter ces méthodes pour assurer un comportement correct. Dans ce chapitre, nous utilisons les termes equals et hashcode pour faire référence respectivement aux méthodes equals...

Log4j, SLF4J et Logback

Dans le domaine de la journalisation en Java, Log4j a longtemps été le système standard pour enregistrer des messages d’information, de débogage et d’erreur. Cependant, la bibliothèque Logback (http://logback.qos.ch/) est apparue comme une alternative plus performante que Log4j.

Il est important de noter qu’avec Log4j, des préoccupations de sécurité ont été identifiées, notamment dans les versions antérieures à la 2.17. Ces problèmes de sécurité ont été adressés dans les versions plus récentes de Log4j.

Historiquement, Jakarta Commons Logging (JCL) était une des premières API de journalisation, mais elle était limitée dans ses fonctionnalités. Vers 2006, des projets majeurs comme Hibernate ont commencé à utiliser l’API SLF4J (http://www.slf4j.org/), contribuant à sa popularité. SLF4J a apporté des améliorations significatives, mais n’a pas complètement supplanté Log4j.

L’un des avantages de SLF4J est sa capacité à centraliser dans un seul ensemble de fichiers de logs les appels effectués par différentes API de journalisation, telles que JCL, Log4j et JUL (Java Util Logging - http://docs.oracle.com/javase/8/docs/api/java/util/logging/package-summary.html). Cela permet...

Bases de données H2 et HSQLDB