token-validation-spring-test ødelegger loggeformatet for appen min

[ahusby]

Jeg har såvidt begynt å forberede meg til oppgradering til versjon >= 3.0.0 av spring-boot-starter-parent. I den forbindelse la jeg inn token-validation-spring-test i pom.xml fila mi. Konsekvensen ble at loggeformatet i apploggen (Kibana/logs.adeo.no) til appen ble feil: Feltet level (loglevel) og component (navnet på den loggende klassen) fikk ingen verdi, message inneholdt både level og timestamp, og jeg tror jeg mistet exceptions/stacktraces. Jeg tenkte jeg skulle tipse om dette i tilfelle biblioteket bundler noe loggkonfig som det ikke trenger å gjøre. Det var litt skummelt, for vi kjørte i en måned i prod før jeg oppdaget dette.

Må understreke at det kan godt hende at det var min egen feil fordi jeg ikke har brukt biblioteket riktig ennå. F.eks. har jeg ikke brukt test scope i pom, og har hatt den i pom samtidig med den gamle token-validation-test-support. Fiksen min, hvis dette er aktuelt å se nærmere på: https://github.com/navikt/rekrutteringsbistand-kandidat-api/pull/206

[ahusby]

@frodank har en ide: "Kanskje biblioteket påvirker hvilke Spring-profiler som er satt, og dermed hvilken logback-fil som brukes i appen?"

[jan-olaveide]

Siste først @ahusby , spring profiler er ikke i bruk i dette biblioteket.
Jeg mener vel at det ikke er noen av modulene i token-support sin business å supplere en logback konfig fil, og om det gjøres andre steder enn med logback-test.xml er det en feil. Men forstår jeg deg rett når. du sier at du drar inn noen av test-support modulene uten test-scope slik at det vil finnes logback fi derfra på classpath runtime? Isåfall ville jeg endret scope på disse artifaktene. Jeg skal ta en kritisk gjennomgang av logback konfig filer også.

[ahusby]

Grunnen til at jeg la inn token-validation-spring-test i pom.xml uten å bruke test-scope er at vi har tester hvor appen startes opp på laptop som om den kjørte i miljø (laptopen er jo på en måte et miljø), hvor testkoden sender en HTTP-request til appens restish API og hvor vi har stubbet avhengigheter utenfor appen med Wiremock. I følge dokumentasjonen som henviser til dette eksemplet ser det ut som det skulle gå bra.