NPE with shared Keycloak dev services when exiting Quarkus dev mode

[nielspardon]

Describe the bug

I have two Quarkus apps with separate Gradle builds and I am using shared Keycloak dev services. When I exit the Quarkus dev mode with q + ENTER I get the following error message with the app that is reusing the shared Keycloak dev service from the other one:

2023-06-08 09:12:52,339 ERROR [io.qua.oid.dep.dev.key.KeycloakDevServicesProcessor] (Quarkus Shutdown Thread) Failed to stop Keycloak container [Error Occurred After Shutdown]: java.lang.NullPointerException: Cannot invoke "java.io.Closeable.close()" because "this.closeable" is null
        at io.quarkus.deployment.builditem.DevServicesResultBuildItem$RunningDevService.close(DevServicesResultBuildItem.java:90)
        at io.quarkus.oidc.deployment.devservices.keycloak.KeycloakDevServicesProcessor$1.run(KeycloakDevServicesProcessor.java:217)
        at io.quarkus.deployment.builditem.CuratedApplicationShutdownBuildItem$1.run(CuratedApplicationShutdownBuildItem.java:48)
        at io.quarkus.bootstrap.classloading.QuarkusClassLoader.close(QuarkusClassLoader.java:617)
        at io.quarkus.bootstrap.app.CuratedApplication.close(CuratedApplication.java:418)
        at io.quarkus.deployment.dev.IsolatedDevModeMain.close(IsolatedDevModeMain.java:356)
        at io.quarkus.deployment.dev.IsolatedDevModeMain$6.run(IsolatedDevModeMain.java:466)
        at java.base/java.lang.Thread.run(Thread.java:833)

Expected behavior

I would not expect it to throw an exception.

Actual behavior

It throws an NPE.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

openjdk 17.0.7 2023-04-18 OpenJDK Runtime Environment Temurin-17.0.7+7 (build 17.0.7+7) OpenJDK 64-Bit Server VM Temurin-17.0.7+7 (build 17.0.7+7, mixed mode, sharing)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.16.6.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Gradle 7.6.1

Additional information

No response

[quarkus-bot]

/cc @geoand (devservices), @pedroigor (keycloak), @sberyozkin (keycloak), @stuartwdouglas (devservices)

[sberyozkin]

Thanks @nielspardon.

@jmartisk Hi Jan, do you recall if you had a similar set up for your book ? I recall you were fixing a few NPEs, do you recall what version it was working with ?

[jmartisk]

My problem was in build-time processing (#29946), this doesn't look much related

[sberyozkin]

@nielspardon Can you please try Quarkus 3.1.2.Final ?

I've tried to reproduce it on main, with quarkus-quickstarts/security-openid-connect-quickstart:

1. mvn quarkus:dev in security-openid-connect-quickstart
2. cp -R security-openid-connect-quickstart security-openid-connect-quickstart2
3. In security-openid-connect-quickstart2 replace quarkus.keycloak.devservices.realm-path=quarkus-realm.json with quarkus.keycloak.devservices.create-realm=false in application.properties to avoid the realm conflict, and then mvn quarkus:dev -Ddebug=5006 -Dquarkus.http.port=8082
4. Press q In security-openid-connect-quickstart2, devmode exits, no NPE reported

[sberyozkin]

@nielspardon If this NPE persists for you even in 3.1.2.Final then please create a simple reproducer so that I can follow steps similar to the ones I described above for the security-openid-connect-quickstart, thanks

[sberyozkin]

Updated my reproducer steps to avoid the port conflicts

[nielspardon]

Thanks for the quick response. I will provide a reproducer early next week.

[nielspardon]

Here's a reproducer using Quarkus 2.16.7.Final
https://github.com/nielspardon/keycloak-reproducer

And here's a branch with the same reproducer migrated to Quarkus 3.1.2.Final
https://github.com/nielspardon/keycloak-reproducer/tree/quarkus-3

[sberyozkin]

Thanks @nielspardon

[sberyozkin]

@nielspardon I opened a simple PR to avoid this NPE, sorry I asked you to create a reproducer, it should've been obvious to me the shared representation of the service has no its own image running :-).
But your reproducer shows an interesting option for testing OIDC client (by the way, you can use @OidcClient annotation as opposed to registering the filter directly with the REST client)

[nielspardon]

@nielspardon I opened a simple PR to avoid this NPE, sorry I asked you to create a reproducer, it should've been obvious to me the shared representation of the service has no its own image running :-). But your reproducer shows an interesting option for testing OIDC client (by the way, you can use @OidcClient annotation as opposed to registering the filter directly with the REST client)

no worries, I just had to find the time to prepare the reproducer. I can understand that it might be helpful to see some context.