Named Redis client injection not working when used in separate JAR

[abutic]

Describe the bug
We have an application scoped bean, defined in our common project and being used by other services, that utilizes RedisClient:

@ApplicationScoped
public class Service {

    @Inject
    @RedisClientName("second")
    RedisClient redisClient;
    ...
}

This common project is packaged as JAR and then used as a Maven dependency from other services.

We keep getting this error when starting those other services:

javax.enterprise.inject.spi.DeploymentException:
  javax.enterprise.inject.UnsatisfiedResolutionException: Unsatisfied dependency for type io.quarkus.redis.client.RedisClient and qualifiers [@RedisClientName(value = "second")]

We've defined an alternate Redis connection like this:

quarkus.redis.second.hosts=redis://localhost:6379

and made sure it's being used as expected by a Redis client defined in our service (not the common JAR!) like this:

    @Inject
    @RedisClientName("second")
    RedisClient redisClient;

Should it be possible to have a bean class contained in a dependency JAR and make it use Redis connection defined in the project that uses that JAR?

Expected behavior
Bean defined in a dependency JAR, which uses a Redis client annotated by @RedisClientName, properly using Redis connection defined in containing service.

[quarkus-bot]

/cc @cescoffier, @gsmet, @machi1990, @manovotn, @mkouba

[manovotn]

This common project is packaged as JAR

Does the JAR contain beans.xml? Empty one should do the trick.

[abutic]

This common project is packaged as JAR

Does the JAR contain beans.xml? Empty one should do the trick.

Unfortunately, yes, the JAR contains an empty META-INF\beans.xml file.

[manovotn]

Hmm, not sure why you cannot see it then.
You could try to make the bean @Unremovable (or just check in dev mode that it wasn't removed) to make double sure something isn't going wrong there.
Besides that, a reproducer project would be nice so that we can check what's going on close up.

[mkouba]

It seems that the redis client extension only considers classes from the application root (i.e. src/main/java) when collecting the client names and registering the relevant synthetic beans: https://github.com/quarkusio/quarkus/blob/master/extensions/redis-client/deployment/src/main/java/io/quarkus/redis/client/deployment/RedisClientProcessor.java#L89-L93

CC @machi1990

[glefloch]

If this consists of looking in all archive classes and adding a test, I can take care or it :)

[machi1990]

It seems that the redis client extension only considers classes from the application root (i.e. src/main/java) when collecting the client names and registering the relevant synthetic beans: https://github.com/quarkusio/quarkus/blob/master/extensions/redis-client/deployment/src/main/java/io/quarkus/redis/client/deployment/RedisClientProcessor.java#L89-L93

CC @machi1990

Thanks for spotting this @mkouba . What archive should have been used instead? I think the same problem can occur for the mongo-extension-

quarkus/extensions/mongodb-client/deployment/src/main/java/io/quarkus/mongodb/deployment/MongoClientProcessor.java

Line 119 in 33364c8

public void mongoClientNames(ApplicationArchivesBuildItem applicationArchivesBuildItem,

/cc @glefloch

[manovotn]

I'd try with BeanArchiveIndexBuildItem.