- Java 98.5%
- Shell 1.2%
- Dockerfile 0.3%
0b30744498* Upgrade Java 21 -> 25
Quarkus ondersteunt Java 25 sinds 3.31; deze service draait al op 3.37.0.
- pom.xml: maven.compiler.release 21 -> 25
- CI: setup-java 21 -> 25 (temurin)
- Runtime-images: ubi9/openjdk-21:1.24 -> ubi9/openjdk-25:1.24 (digest opnieuw
gepind, multi-arch amd64/arm64/ppc64le/s390x)
- ClusterFuzzLite: base-builder-jvm draait op Ubuntu 20.04 en heeft geen
openjdk-25 pakket, dus Temurin 25 uit de tarball (versie + sha256 gepind).
Gebundelde runtime open-jdk-21 -> open-jdk-25.
- README: vereiste Java-versie bijgewerkt.
De jib-extensie kiest zijn base image op basis van de gecompileerde release en
schakelt vanaf Java 25 automatisch naar ubi9/openjdk-25-runtime; daar is dus
geen configuratie voor nodig.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Repareer dekkingsmeting en dicht de grootste testgaten
De JaCoCo-agent hing alleen aan prepare-agent-integration (pre-integration-test),
dus surefire draaide zonder agent. Alle gemeten dekking kwam van de quarkus-jacoco
extensie, die uitsluitend @QuarkusTest-klassen registreert. Gewone unittests telden
daardoor voor 0% mee: IdentificatieNummerValidator stond op 0% ondanks 31 groene
tests, en jacoco:check sloeg stilzwijgend over als het exec-bestand ontbrak.
- pom.xml: prepare-agent toegevoegd zodat surefire wel meet;
quarkus.jacoco.reuse-data-file=true zodat de extensie het bestand niet wist.
Alleen die fix bracht de meting van 85.2%/72.3% naar 89.0%/83.7%.
- Drempels van 0.5/0.5 naar 0.85/0.80 nu de meting klopt.
Nieuwe tests voor wat daarna echt ongedekt bleek:
- TeVerwijderenOpControllerIntegrationTest: beide PATCH .../te-verwijderen-op
endpoints hadden nul HTTP-aanroepen (21 regels controller ongedekt); nu 200,
404, 403, 400-in-verleden, 400-boven-7-jaar en lege body, inclusief validatie
tegen de OpenAPI-spec.
- PartijServiceScopeFilterTest: scope-filtering per dienstverlener/dienst werd
nergens geraakt terwijl het bepaalt welke gegevens een dienstverlener ziet.
Ook de scope-varianten in resolveDienstverlenerDienst en de upsert-invariant
per (partij, voorkeurType, scope).
- PartijMapperTest: het schrijf-neveneffect bij stale rijen, inclusief het
opruimen van een automatisch gezette bewaartermijn.
- DatabaseConstraintViolationMapperTest: de 409-afhandeling van een unique
constraint race, die via HTTP niet betrouwbaar te reproduceren is.
- ProblemsTest: statuscodes en het problem+json-lichaam (RFC 9457).
- EmailVerificatieServiceTest: contact wordt op type én waarde gematcht, zodat
een Telefoonnummer met e-mailachtige waarde niet als e-mail geverifieerd raakt.
223 tests groen, 95.0% line / 93.3% branch.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Verwijder TeVerwijderenOpControllerIntegrationTest
Het te-verwijderen-op veld verdwijnt in een aparte story, dus deze endpoints
nu afdekken voegt niets toe.
Dekking blijft 93.0% line / 90.4% branch en daarmee ruim boven de drempels.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Negeer alleen .claude/settings.local.json in plaats van heel .claude/
Met .claude/ volledig genegeerd reist project-configuratie niet mee naar een
git worktree, want een worktree krijgt alleen wat in git zit. Skills, commands
en gedeelde settings horen wel gedeeld te worden; settings.local.json bevat
persoonlijke permissie-keuzes en blijft genegeerd.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Ontdubbel PartijMapperTest na rebase op main
Main heeft in #113 een eigen PartijMapperTest toegevoegd die grotendeels
dezelfde grond dekt als de mijne, met sterkere assertions (exacte waarde van
teVerwijderenOp, en lastUpdated die het moment van teruggedraaien weerspiegelt).
De automatische conflictoplossing hield mijn variant aan en verloor die
assertions daarmee.
Nu main's versie als basis, met daar bovenop de drie gevallen die main niet
had: een verse rij binnen de 24-uursdrempel mag niet worden aangeraakt, en de
retentie-logica op Voorkeur (automatisch teruggedraaid, handmatig behouden).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Verwerk reviewopmerkingen PR #115
- Witregels rond if-statements en vóór afsluitende returns in
PartijServiceScopeFilterTest, conform de codestijl in CLAUDE.md.
- Test toegevoegd waarin één contactgegeven en één voorkeur twee scopes van
dezelfde dienstverlener hebben, zodat de join twee resultaatrijen oplevert
en het ontdubbelen van de response wordt vastgelegd.
- toVoorkeurResponse-tests asserten nu ook dat lastUsedAt is bijgewerkt; in
het handmatige geval blijft de verwijderdatum staan maar moet de
touch-on-read wél zijn uitgevoerd.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Verwijder overbodige distinct uit de scope-filterqueries
Hibernate ontdubbelt entity-resultaten van een join sinds versie 6 zelf, dus
het trefwoord deed hier niets: met en zonder distinct is het resultaat gelijk.
Weggehaald, met een toelichting bij de methode zodat het niet terugkeert als
cargo cult.
Dat de response geen dubbele rijen bevat is wel gedrag waar aanroepers op
leunen, dus dat is nu expliciet afgedekt:
- rijMetTweeMatchendeScopes_KomtSlechtsEenmaalTerug controleert eerst dat de
join daadwerkelijk twee rijen oplevert, zodat de test niet stilzwijgend
vacuum wordt, en daarna dat de rij één keer in de response staat.
- rijMetDienstBredeEnDienstSpecifiekeScope_KomtSlechtsEenmaalTerug dekt
hetzelfde via het dienstNaam-filter.
- ongescopteRijNaastGescopteRij_LevertGeenDubbeleTreffers dekt het pad waarop
beide OR-takken van het filter tegelijk raak zijn.
Geverifieerd met een mutatie: als de filtermethode bewust dubbele rijen
teruggeeft, vallen 10 tests om.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Hernoem eigen tests in EmailVerificatieServiceTest naar Engels
Main heeft dit bestand in
|
||
|---|---|---|
| .clusterfuzzlite | ||
| .github | ||
| .mvn/wrapper | ||
| src | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| CLAUDE.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| docker-compose.yml | ||
| FUZZING.md | ||
| GOVERNANCE.md | ||
| LICENSE | ||
| mvnw | ||
| mvnw.cmd | ||
| pom.xml | ||
| publiccode.yml | ||
| quarkus.md | ||
| README.md | ||
| SECURITY.md | ||
| SUPPORT.md | ||
Profiel Service
De Profiel Service stelt burgers en ondernemers in staat om op één vertrouwde plek hun contactgegevens en communicatievoorkeuren te beheren, en biedt overheidsinstanties via federatieve koppelingen veilige, actuele en herbruikbare profielinformatie voor persoonlijke en efficiënte dienstverlening.
Documentatie over de Profiel Service is te vinden op de documentatie website van MijnOverheidZakelijk.
Status
Levenscyclus: development (zie publiccode.yml). De service draait in een POC-omgeving en wordt voorbereid op landing op de Logius Private Cloud (LPC).
API
- Base path:
/api/profielservice/v1 - OpenAPI spec:
/openapi.json - Swagger UI:
/docs - Health en metrics: op aparte management-port
9090onder/q/healthen/q/metrics(niet via de publieke port).
De API volgt de NL GOV API Design Rules 2.1.0. Foutmeldingen volgen RFC 9457 (application/problem+json).
Lokaal draaien
Vereisten:
- Java 25
- Maven (of de meegeleverde wrapper
./mvnw) - PostgreSQL (of gebruik H2 via het
testprofile)
# Database opstarten (zie docker-compose.yml)
docker compose up -d
# Dev-modus (live reload, http://localhost:8080)
./mvnw quarkus:dev
# Tests (gebruikt H2)
./mvnw verify
Configuratie
Lokale ontwikkel-secrets horen in een gitignored src/main/resources/application-dev.properties:
notifynl.emailverificatie.api-key,template-id,reference— van https://admin.notifynl.nl/, vraag het team voor toegang.quarkus.datasource.*— alleen nodig als je geendocker composegebruikt.
Productie-configuratie staat in de deployment-repo.
Quarkus
Dit project draait op Quarkus. Meer informatie hierover staat in quarkus.md.
Circuit breaker voor de Verificatie-service API
Bij herhaalde fouten in de communicatie met de externe verificatie-service (bijvoorbeeld door netwerkproblemen of uitval) wordt de circuit breaker actief. Na een configureerbaar aantal mislukte aanroepen gaat het circuit open: nieuwe verzoeken worden direct afgewezen zonder dat er opnieuw een verbinding wordt geprobeerd. Dit voorkomt dat de applicatie vastloopt op trage of niet-reagerende externe diensten. Na een wachttijd gaat het circuit in half-open toestand en worden nieuwe aanroepen opnieuw toegestaan om te testen of de externe dienst hersteld is.
De circuit breaker is gedeeld tussen de twee aanroepen naar de verificatie-service (requestEmailVerificationCode en verifieerEmail). Dit betekent dat herhaalde fouten op het ene endpoint ook het andere endpoint beschermen: als de verificatie-service voor de ene aanroep niet bereikbaar is, is dat hoogstwaarschijnlijk voor de andere ook het geval. De gedeelde circuit breaker wordt beheerd via VerificatieServiceGuard.
Circuit breaker instellingen
De circuit breaker wordt geconfigureerd via de volgende properties in application.properties. De waarden in de code gelden als standaardwaarden en kunnen per omgeving worden overschreven.
verificatie-service.circuit-breaker.request-volume-threshold: Minimum aantal aanroepen binnen het meetvenster voordat het circuit kan openen (standaard5).verificatie-service.circuit-breaker.failure-ratio: Drempelwaarde voor het percentage mislukte aanroepen waarboven het circuit opent (standaard1.0— circuit opent alleen bij volledige uitval).verificatie-service.circuit-breaker.delay: Wachttijd in seconden in de open toestand voordat het circuit half-open gaat (standaard30).verificatie-service.circuit-breaker.success-threshold: Aantal opeenvolgende successen in half-open toestand dat nodig is om het circuit te sluiten (standaard2).
Contracttesting
De Profiel Service maakt gebruik van contracttesting om te waarborgen dat wijzigingen aan de API consumenten niet ongemerkt breken.
Hoe het werkt
- OpenAPI-schemavalidatie: elke integratietest valideert automatisch dat verzoeken en antwoorden overeenkomen met de live OpenAPI-specificatie van de service (
/q/openapi). - Pact-providerverificatie: pact-bestanden (JSON) in
src/test/resources/pacts/beschrijven de verwachte contracten. De provider test verifieert dat de service hieraan voldoet. Het huidige bestandmoza-profiel-service.jsonis een zelftestcontract van de provider zelf.
Contracten bijdragen als consument
Ben je consument van de Profiel Service API en wil je een contract bijdragen? Neem dan contact op met het team om dit samen te bespreken. We stellen dan samen een pact-bestand op dat de verwachtingen van jouw toepassing beschrijft.
Een Pact Broker is een mogelijke toekomstige stap, afhankelijk van de behoefte van het team.