quarkus: oidc-client, ContextNotActiveException in new thread
Describe the bug
It seams like Context is lost in the new thread when using Tokens from oidc-client
See also: https://github.com/quarkusio/quarkus/discussions/22273
Expected behavior
Usage of io.quarkus.oidc.client.Tokens should work, ie. have a value
Actual behavior
Usage(@Inject) of io.quarkus.oidc.client.Tokens is causing: ContextNotActiveException
The result from running: MyResourceTest.fail:
javax.ws.rs.ProcessingException: javax.enterprise.context.ContextNotActiveException
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.filterRequest(ClientInvocation.java:780)
at org.jboss.resteasy.microprofile.client.impl.MpClientInvocation.filterRequest(MpClientInvocation.java:75)
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:491)
at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invokeSync(ClientInvoker.java:152)
at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:115)
at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:76)
at com.sun.proxy.$Proxy107.updatestate(Unknown Source)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.resteasy.microprofile.client.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:146)
at com.sun.proxy.$Proxy108.updatestate(Unknown Source)
at org.my.StreamService.lambda$0(StreamService.java:26)
at org.my.AbstractMeglerService.execute(AbstractMeglerService.java:17)
at org.my.StreamService.updateState(StreamService.java:26)
at org.my.StreamService_ClientProxy.updateState(Unknown Source)
at org.my.QConsumer.run(QConsumer.java:35)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: javax.enterprise.context.ContextNotActiveException
at io.quarkus.arc.impl.ClientProxies.getDelegate(ClientProxies.java:46)
at io.quarkus.oidc.client.runtime.TokensProducer_MidtNorge_ProducerMethod_produceTokens_494654c3bfa2346b017c24e2e2c4fcfc99087d0e_ClientProxy.arc$delegate(Unknown Source)
at io.quarkus.oidc.client.runtime.TokensProducer_MidtNorge_ProducerMethod_produceTokens_494654c3bfa2346b017c24e2e2c4fcfc99087d0e_ClientProxy.getAccessToken(Unknown Source)
at org.my.StreamAuthenticationFilterMidtNorge.filter(StreamAuthenticationFilterMidtNorge.java:21)
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.filterRequest(ClientInvocation.java:767)
... 22 more
How to Reproduce?
It is based on: https://quarkus.io/guides/rest-client I added my stuff in the package: org.my
The problem can be verified by running the test: MyResourceTest.fail
The other test: MyResourceTest.ok is doing the same, BUT in same thread (that is not via a Q, as the other test), but it requires proper values in: application.properties to succeed.
Output of uname -a or ver
uname -a Linux hty80028.sb1a.sparebank1.no 4.18.0-348.2.1.el8_5.x86_64 #1 SMP Mon Nov 8 13:30:15 EST 2021 x86_64 x86_64 x86_64 GNU/Linux
Output of java -version
openjdk version “11.0.10” 2021-01-19 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.10+9) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.10+9, mixed mode)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.5.4.Final
Build tool (ie. output of mvnw --version or gradlew --version)
No response
Additional information
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 37 (23 by maintainers)
Ah okay. I misunderstood what it does then.
Thanks
No it’s not, this is directly backed by the Quarkus worker thread pool, so you can block.