Pièges Courants

Guide des erreurs classiques et leurs solutions pour éviter les problèmes avec Micronaut et l’architecture hexagonale.

Apprenez des erreurs courantes pour éviter de perdre des heures de débogage !

1. Lombok ne fonctionne pas dans les Controllers

❌ Symptôme

Symptôme


@Controller
@RequiredArgsConstructor  // ← Ne marche pas !
public class MyController {
    private final MyService service;
}

Erreur : No bean of type MyService available for injection

Conséquences :

❌ Le controller ne démarre pas
❌ Tests échouent
❌ Application ne compile pas correctement

🔍 Cause

Cause

L’ordre des annotation processors dans le pom.xml est incorrect. Si Micronaut est traité avant Lombok, il ne voit pas le constructeur généré.

Pourquoi ? Les annotation processors s’exécutent dans l’ordre :

Lombok génère le constructeur
Micronaut lit le bytecode et voit le constructeur → crée l’injection

Ordre inversé = Micronaut ne voit rien → pas d’injection.

✅ Solution

Solution

Mettre Lombok EN PREMIER dans annotationProcessorPaths :


<annotationProcessorPaths>
    <!-- ✅ 1. LOMBOK D'ABORD -->
    <path>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.36</version>
    </path>
 
    <!-- ✅ 2. MICRONAUT APRÈS -->
    <path>
        <groupId>io.micronaut</groupId>
        <artifactId>micronaut-inject-java</artifactId>
        <version>${micronaut.version}</version>
    </path>
</annotationProcessorPaths>

Après avoir modifié le pom.xml, lancez mvn clean compile pour régénérer les métadonnées.

2. Jackson ne peut pas désérialiser mon DTO avec @Value

❌ Symptôme

Symptôme


@Value
public class TrendResponseDto {
    String keyword;
    Integer score;
}

Erreur dans les tests :


Cannot construct instance of `TrendResponseDto`
(no Creators, like default constructor, exist)

Problème :

❌ Les tests qui désérialisent le JSON échouent
❌ Impossible de mapper les réponses HTTP

🔍 Cause

Cause

@Value génère un constructeur avec tous les paramètres
Jackson ne sait pas comment mapper {"keyword": "java"} vers les paramètres
Java ne garde pas les noms de paramètres (keyword, score) après compilation par défaut

Exemple :


// Ce que Jackson voit après compilation
public TrendResponseDto(String arg0, Integer arg1) { }
 
// Jackson ne sait pas que arg0 = keyword et arg1 = score !

✅ Solution Complète

Solution complète (3 étapes)

Ajouter le module Jackson


<dependency>
    <groupId>com.fasterxml.jackson.module</groupId>
    <artifactId>jackson-module-parameter-names</artifactId>
</dependency>

Activer -parameters dans le compiler


<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <parameters>true</parameters>  <!-- ← IMPORTANT -->
    </configuration>
</plugin>

Ce flag dit au compilateur de garder les noms des paramètres dans le .class.

Activer le scan Jackson

Dans application.yml :


jackson:
  module-scan: true

Après cette configuration, Jackson pourra désérialiser les DTOs avec @Value.

Alternative

Alternative simple

Utiliser @Data avec un constructeur vide :


@Data
@NoArgsConstructor  // Pour Jackson
@AllArgsConstructor
public class TrendResponseDto {
    String keyword;
    Integer score;
}

Avantage : Fonctionne immédiatement.

Inconvénient : Vous perdez l’immutabilité.

Préférez la solution complète pour garder l’immutabilité avec @Value.

3. Erreur “reference to assertThat is ambiguous”

❌ Symptôme

Symptôme

Dans les tests :


assertThat(response.getStatus()).isEqualTo(HttpStatus.OK);

Erreur : reference to assertThat is ambiguous

Résultat :

❌ Les tests ne compilent pas
❌ IDE affiche des erreurs

🔍 Cause

Cause

Conflit entre plusieurs bibliothèques ayant assertThat :

org.assertj.core.api.Assertions.assertThat (AssertJ)
org.hamcrest.MatcherAssert.assertThat (Hamcrest, inclus par micronaut-test)

Le compilateur ne sait pas lequel utiliser !

✅ Solution 1

Solution 1 : N’utiliser QUE AssertJ


// ✅ Imports corrects
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;
 
// ❌ Ne pas mélanger
import static org.junit.jupiter.api.Assertions.assertThrows;  // Non !

Pour les exceptions, utiliser assertThatThrownBy d’AssertJ :


// ✅ AssertJ
assertThatThrownBy(() -> client.toBlocking().exchange(request))
    .isInstanceOf(HttpClientResponseException.class)
    .satisfies(e -> {
        HttpClientResponseException ex = (HttpClientResponseException) e;
        assertThat(ex.getStatus()).isEqualTo(HttpStatus.BAD_REQUEST);
    });

Utilisez uniquement AssertJ pour éviter les conflits.

✅ Solution 2

Solution 2 : Cast explicite pour HttpStatus

Si l’erreur persiste sur response.getStatus() :


// ✅ Cast explicite
assertThat((CharSequence) response.getStatus()).isEqualTo(HttpStatus.OK);
 
// Ou
assertThat((Object) response.getStatus()).isEqualTo(HttpStatus.OK);

Pourquoi ? HttpStatus implémente CharSequence, ce qui crée une ambiguïté entre les overloads d’AssertJ.

4. Mon bean n’est pas injecté

❌ Symptôme

Symptôme


No bean of type [MyService] exists

Conséquences :

❌ Application ne démarre pas
❌ Tests échouent
❌ NullPointerException au runtime

Cause A: @Singleton

Cause A : Tu as oublié l’annotation @Singleton


// ❌ Pas un bean
public class MyService {
}
 
// ✅ Bean
@Singleton
public class MyService {
}

Sans @Singleton, Micronaut ne crée pas de bean et ne peut pas l’injecter.

Autres annotations valides :

@Controller (inclut @Singleton)
@Factory

Cause B: @Primary

Cause B : Plusieurs implémentations sans @Primary


@Singleton
public class MockRepository implements Repository { }
 
@Singleton
public class RealRepository implements Repository { }
 
// Micronaut ne sait pas lequel injecter !

Solution :


@Singleton
@Primary  // ← Celui par défaut
public class MockRepository implements Repository { }
 
@Singleton
@Named("real")
public class RealRepository implements Repository { }

Injection :


@Inject
@Named("real")
private Repository repo;

Utilisez @Primary pour l’implémentation par défaut et @Named pour les alternatives.

Cause C: Package

Cause C : Le bean est dans un package non scanné

Par défaut, Micronaut scanne le package de la classe Application.

Si ton bean est dans com.other.package, il ne sera pas trouvé.

Solution : Mettre tous tes beans dans le même package racine que Application.java.


✅ BON
org.smoka
├── Application.java
├── domain/
├── application/
└── infrastructure/

❌ MAUVAIS
org.smoka
├── Application.java
└── domain/

com.other.package  // ← Non scanné !
└── MyService.java

5. GlobalExceptionHandler ne marche pas (PIÈGE PSYCHO)

❌ Symptôme

Symptôme

Tu as créé un GlobalExceptionHandler mais les exceptions ne sont pas interceptées.


@Singleton
@Produces
public class GlobalExceptionHandler implements ExceptionHandler<Exception, HttpResponse<ErrorResponse>> {
    // Pas appelé !
}

Résultat :

❌ Erreurs 500 au lieu de 404/400
❌ Tests échouent
❌ Messages d’erreur par défaut de Micronaut

🔍 Cause 1

Cause 1 : @Requires trop restrictif


@Singleton
@Produces
@Requires(classes = {ExceptionHandler.class})  // ← PROBLÈME !
public class GlobalExceptionHandler implements ExceptionHandler<Exception, HttpResponse<ErrorResponse>> {
}

Solution : Retirer @Requires :


// ✅ Bon
@Slf4j
@Singleton
@Produces
public class GlobalExceptionHandler implements ExceptionHandler<Exception, HttpResponse<ErrorResponse>> {
}

@Requires peut empêcher le bean d’être créé dans certains environnements.

🔍 Cause 2 (VICIEUX)

Cause 2 : Tu testes les erreurs gérées par Micronaut (PIÈGE VICIEUX)

Le piège : Micronaut a des handlers intégrés plus spécifiques que le tien !


// ❌ CE TEST NE MARCHERA JAMAIS
@Test
void shouldReturn400WhenKeywordIsMissing() {
    // Micronaut gère les @QueryValue manquants avec SON handler
    // Ton GlobalExceptionHandler n'est JAMAIS appelé !
    client.toBlocking().exchange(HttpRequest.GET("/api/trends"));
}

Pourquoi ? Micronaut a une hiérarchie de handlers :

Handlers spécifiques (validation, binding, etc.) → priorité haute
Ton GlobalExceptionHandler → priorité basse

Les erreurs suivantes sont déjà gérées par Micronaut :

❌ @QueryValue manquant
❌ @PathVariable invalide
❌ @Body mal formé
❌ Erreurs de parsing JSON

Ton handler ne catch QUE :

✅ Tes exceptions custom (ResourceNotFoundException, etc.)
✅ Les RuntimeException non gérées
✅ Les erreurs métier

✅ Solution

Solution : Créer un controller de test

Pour tester TON handler, crée un endpoint qui lance TES exceptions :


@Controller("/test-exceptions")
@Requires(env = Environment.TEST)  // Uniquement en test
public class TestExceptionController {
 
    @Get("/resource-not-found")
    public String throwResourceNotFound() {
        throw new ResourceNotFoundException("Test resource");
    }
 
    @Get("/generic-error")
    public String throwGenericError() {
        throw new RuntimeException("Test error");
    }
}

Maintenant tu peux tester :


@Test
void shouldReturn404ForResourceNotFound() {
    assertThatThrownBy(() ->
        client.toBlocking().exchange(HttpRequest.GET("/test-exceptions/resource-not-found"))
    )
    .satisfies(e -> {
        HttpClientResponseException ex = (HttpClientResponseException) e;
        assertThat((CharSequence) ex.getStatus()).isEqualTo(HttpStatus.NOT_FOUND);
 
        ErrorResponse error = ex.getResponse().getBody(ErrorResponse.class).orElse(null);
        assertThat(error).isNotNull();
        assertThat(error.getStatus()).isEqualTo(404);
        assertThat(error.getMessage()).contains("Test resource");
    });
}

Morale : Ne teste PAS les erreurs de Micronaut, teste TES exceptions custom !

Récapitulatif

Type d’erreur	Géré par	Ton handler appelé ?
`@QueryValue` manquant	Micronaut	❌ Non
`@Valid` échoue	Micronaut	❌ Non
JSON invalide	Micronaut	❌ Non
`ResourceNotFoundException`	TON HANDLER	✅ Oui
`RuntimeException` non géré	TON HANDLER	✅ Oui

6. Le Domain dépend de Jackson (VIOLATION ARCHITECTURE)

❌ Symptôme

Symptôme


// ❌ domain/model/Country.java
@Value
public class Country {
    @JsonProperty("name")  // ❌ Jackson dans le domain !
    Name name;
}

Conséquences :

❌ Tests d’architecture échouent
❌ Domain couplé à Jackson
❌ Impossible de changer de librairie

🔍 Problème

Problème

Le domain dépend de Jackson → impossible de changer de librairie sans casser le domain.

Violation du principe : Le domain doit être pur et ne dépendre de rien.


❌ MAUVAIS
Domain → Jackson

✅ BON
Infrastructure → Jackson
Domain → Rien

✅ Solution

Solution

DTOs dans l’infrastructure :


// ✅ infrastructure/dto/CountryApiDto.java
@Data
@NoArgsConstructor
public class CountryApiDto {
    @JsonProperty("name")  // ✅ Jackson dans l'infrastructure
    private NameDto name;
}
 
// ✅ domain/model/Country.java
@Value
public class Country {
    Name name;  // ✅ Pas de Jackson, juste du Java pur
}

Conversion dans l’adaptateur :


// infrastructure/adapter/CountryRepositoryAdapter.java
private Country toDomain(CountryApiDto dto) {
    Name name = new Name(
        dto.getName().getCommon(),
        dto.getName().getOfficial()
    );
    return new Country(name);
}

Le domain reste pur, Jackson est isolé dans l’infrastructure !

7. Mon test échoue de façon aléatoire

❌ Symptôme

Symptôme


@Test
void topicsShouldBeSortedByScore() {
    var topics = api.getTopics();
    assertThat(topics.get(0).getScore())
        .isGreaterThan(topics.get(1).getScore());
}

Résultat : Parfois ça passe, parfois ça échoue.

Problème :

❌ Tests instables
❌ CI/CD aléatoire
❌ Difficile à déboguer

🔍 Cause

Cause

Ton mock génère des données aléatoires :


private List<Topic> generateTopics() {
    return List.of(
        new Topic("java tutorial", 80 + random.nextInt(20)),  // 80-100
        new Topic("java guide", 70 + random.nextInt(30))      // 70-100
    );
}

Problème : “java guide” peut avoir un score > “java tutorial” !


Test 1: [95, 72] → ✅ Passe
Test 2: [82, 98] → ❌ Échoue

✅ Solution 1

Solution 1 : Trier les résultats dans le mock


private List<Topic> generateTopics() {
    List<Topic> topics = List.of(
        new Topic("java tutorial", 80 + random.nextInt(20)),
        new Topic("java guide", 70 + random.nextInt(30))
    );
 
    // Trier par score décroissant
    return topics.stream()
        .sorted(Comparator.comparingInt(Topic::getScore).reversed())
        .collect(Collectors.toList());
}

Les résultats sont toujours triés, le test est stable !

✅ Solution 2

Solution 2 : Utiliser une seed fixe pour les tests


@Singleton
public class MockRepository {
    private final Random random;
 
    public MockRepository(@Value("${test.seed:#{null}}") Long seed) {
        this.random = seed != null ? new Random(seed) : new Random();
    }
}

Dans application-test.yml :


test:
  seed: 42  # Résultats reproductibles

Avec une seed fixe, les tests produisent toujours les mêmes résultats.

8. Mon endpoint retourne 404

❌ Symptôme

Symptôme


@Controller("/api/trends")
public class TrendController {
    @Get
    public TrendResponseDto getTrends() { }
}

Appel à GET /api/trends → 404

Résultat :

❌ Endpoint non trouvé
❌ Tests échouent

Cause A: Bean

Cause A : Le controller n’est pas un bean


// ❌ Pas un bean
public class TrendController { }
 
// ✅ Bean
@Controller("/api/trends")
public class TrendController { }

@Controller inclut automatiquement @Singleton, donc le controller devient un bean.

Cause B: Chemin

Cause B : Mauvais chemin


@Controller("/api/trends")
public class TrendController {
    @Get("/search")  // ← Le chemin complet est /api/trends/search
    public TrendResponseDto getTrends() { }
}

Appeler :

❌ GET /api/trends → 404
✅ GET /api/trends/search → 200

Solution : Vérifier le chemin complet.

Cause C: Compilation

Cause C : Erreur de compilation

Si Micronaut n’a pas généré les métadonnées :


mvn clean compile

Vérifie target/classes/META-INF/services/.

Après avoir modifié des annotations, toujours recompiler avec mvn clean compile.

9. mvn test ne trouve pas mes tests

❌ Symptôme

Symptôme


[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

Problème :

❌ Aucun test exécuté
❌ Code non testé
❌ Couverture 0%

Cause A: Nom

Cause A : Nom de fichier incorrect

Les tests doivent se terminer par Test ou Tests :

✅ TrendControllerTest.java
❌ TrendControllerTestCase.java

Maven Surefire cherche les fichiers *Test.java, *Tests.java, et Test*.java.

Cause B: @Test

Cause B : Méthodes non annotées @Test


// ❌ Pas reconnu
void shouldReturnTrends() { }
 
// ✅ Reconnu
@Test
void shouldReturnTrends() { }

Cause C: Visibilité

Cause C : Classe non public


// ❌ Package-private
class TrendControllerTest { }
 
// ✅ Public
public class TrendControllerTest { }

Toujours déclarer les classes de test public.

Checklist de débogage

Quand quelque chose ne marche pas :

Recompiler


mvn clean compile

Vérifier l’ordre Lombok/Micronaut

Dans le pom.xml, Lombok doit être AVANT Micronaut.

Vérifier les annotations

@Singleton, @Controller, @Inject
Pas de @Requires inutiles (surtout sur les ExceptionHandler)

Consulter les logs

Micronaut affiche ce qu’il crée au démarrage :


INFO  io.micronaut.runtime.Micronaut - Startup completed in 1234ms

Vérifier les imports

Pas de mélange AssertJ/Hamcrest/JUnit.

Cast pour HttpStatus


assertThat((CharSequence) response.getStatus()).isEqualTo(HttpStatus.OK);

Flag -parameters

Activé dans le compiler Maven pour Jackson.

Relancer l’IDE

IntelliJ peut avoir un cache obsolète.

Résumé

Évitez ces pièges courants pour gagner du temps et éviter la frustration !

Piège	Symptôme	Solution
Lombok avant Micronaut	Bean pas injecté	Ordre dans `pom.xml`
Jackson + @Value	Cannot construct instance	`-parameters` + module Jackson
assertThat ambiguous	Erreur compilation	Utiliser uniquement AssertJ
Bean pas injecté	No bean exists	`@Singleton` + bon package
GlobalExceptionHandler	Pas appelé	Retirer `@Requires` + tester TES exceptions
Jackson dans Domain	Tests archi échouent	DTOs dans infrastructure
Tests aléatoires	Instabilité	Trier ou seed fixe
Endpoint 404	Not found	Vérifier chemin + bean + compilation
Tests non trouvés	0 tests run	Nom `*Test.java` + `@Test` + `public`

Prochaines étapes

Maintenant que vous connaissez les pièges, explorez les bonnes pratiques pour un code propre.

Code Propre → - SOLID, DDD, conventions
Tests d’Architecture → - Éviter les violations automatiquement
Performance → - Optimisations Micronaut

Ressources

Concepts Micronaut → - Concepts de base
Tests d’Intégration → - Guide complet des tests
Documentation Micronaut