Dans une application Spring, sauf exceptions, les Beans sont proxifiés. En d’autres mots, on n’interagit pas directement avec eux et ce mécanisme est à la base de l’AOP.
Beaucoup de mécanismes s’appuient sur l’AOP (les Transactions par exemple) et connaître la façon dont sont proxifiés les beans est important pour prédire et comprendre certains comportements.
La documentation Spring est très claire sur la question:
If the target object to be proxied implements at least one interface, a JDK dynamic proxy is used. All of the interfaces implemented by the target type are proxied. If the target object does not implement any interfaces, a CGLIB proxy is created.
Quand, dans mon application Spring Boot j’avais mon Bean proxifié par CGLIB alors qu’il implémentait une interface, j’ai donc cru à une erreur mais que nenni !
Dans une application Spring Boot, depuis Spring Boot 2, c’est CGLIB qui est utilisé en priorité, même quand un Bean implémente une interface ! Attention donc si vous annotez @Transactionnal sur une méthode final (vous n’aurez pas d’erreur mais la transaction ne s’effectuera pas).
Avoir le même comportement qu’une application Spring classique
Si vous souhaitez avoir les mêmes règles que dans une application Spring classique, dans votre application.properties, ajoutez la ligne suivante:
spring.aop.proxy-target-class=false
Astuces
Vous pouvez utiliser
AopUtils.isCglibProxy(monBean);
Ou
AopUtils.isJdkDynamicProxy(monBean);
Pour savoir quel proxy est utilisé.
Vous pouvez bien évidemment utiliser le débugger pour vous en rendre compte également.
Il arrive que la code review nous empêche de merge nos PR assez vite et qu’on se retrouve à tirer une branche d’une branche de travail pour avancer 😔
Une fois la première PR squash et merge, la PR issue de la seconde branche se retrouve avec des conflits 💥
Si vous avez déjà vécu cette situation, il y a de bonnes chances que vous ayez cherry-pick vos commits de travail sur une...
Il arrive souvent que pour tester unitairement des règles de validation, on doive tester le même cas mais avec des exemples différents. Sans tests paramétrés, ça revient à faire un test par cas ce qui peut alourdir notre fichier de tests.
On va voir comme...
Avant .Net 8, tester du code qui utilise DateTime.Now() n’était pas trivial, on devait faire en sorte de mocker la Clock dans nos tests. Depuis .Net 8, c’est beaucoup plus facile grâce à TimeProvider inclut par défaut !
En deux mots, TimeProvider est une...
La gestion des erreurs de son API est très importante pour que les consommateurs puissent avoir une description claire du problème mais c’est souvent fastidieux à maintenir.
On va voir comment avoir des statuts de réponse cohérent et des messages d’erre...