Quarkus dependency injection not discriminating on uriInfo being injectable or not

I am not sure this is a bug, I think that this is more me not knowing how to properly use Dependency Injection within Quarkus.

I have the following setup in Kotlin with Quarkus 2.16.3:

interface Resolver {
    fun getInfo(): String
}

@ApplicationScoped
@Default
@Priority(1)
class ResolverNoRequest(): Resolver {
    override fun getInfo(): String {
        return "myInfo"
    }
}

@RequestScoped
@Alternative
@Priority(2)
class ResolverWithRequest(val uriInfo: UriInfo) : Resolver {
    override fun getInfo(): String {
        val hostname = uriInfo.baseUri.host
        return "myInfo with $hostname"
    }
}

I have another class that get injected like this

@ApplicationScoped
class Consumer(val resolver: Resolver){
	
	fun process(){
		println(resolver.getInfo())
	}
}

What I would like to have is:

• In the context of a request: the "ResolverWithRequest" is injected (if started with a batch)
• When there is no request: the "ResolverNoRequest" is injected (if started from a rest endpoint)

I have tweaked (actually alot) with the annotations, and changed the signature of Consumer to have Instance<Resolver>.
But I did not manage to get them by discriminating on whether the uriInfo is there or not.
In fact when the ResolverWithRequest is proposed (when there is no request) it crashes because there is no uriInfo ( java.lang.IllegalStateException: No RESTEasy Reactive request in progress).
I would have expected the Consumer not to get injected with the ResolverWithRequest in case of no request.

The only (very ugly) solution I found on my own is to have Instance<Resolver> with a try catch block.

I am persuaded that Quarkus is an elegant framework, and I think I am missing something.

It would be awesome if someone could help on this

Here is the little extract I have made so that you can reproduce on your end without friction:
https://github.com/olivierbeltrandocintoo/quarkus_kotlin_mini_injection_issues

It can't be done this easily, because dependencies are resolved based on their type and qualifiers, and nothing else. Therefore, you will always get your ResolverWithRequest, because it is an enabled alternative (and has highest priority).

However, you can create your own facade that will dispatch to the correct Resolver based on whatever criteria you need.

@ApplicationScoped
@Alternative
@Priority(10)
class DispatchingResolver(
        val global: ResolverNoRequest,
        val perRequest: ResolverWithRequest
): Resolver {
    override fun getInfo(): String {
        if (isRequestActive()) {
            return perRequest.getInfo()
        } else {
            return global.getInfo()
        }
    }
}

(Note that I might be making some lousy mistakes, as I don't write Kotlin daily, but I guess you know what I mean.)

This works correctly, because both ResolverNoRequest and ResolverWithRequest are normal-scoped beans and hence the objects injected into DispatchingResolver's constructor are client proxies. A client proxy will only obtain the actual bean instance upon method invocation.

Now, how do I find out if a request is active? There's probably more than one way, but here's one. CDI's BeanManager lets you obtain a context object for given scope (BeanManager.getContext()), except that throws an exception. ArC has a method will just return a null context if the context is not active: ArcContainer.getActiveContext(). So you can do this:

fun isRequestActive() = Arc.container().getActiveContext(RequestScoped.class) != null

Hope that helps.