@ConfigProperty not working in ContextResolver

[abelsromero]

Describe the bug
Properties marked for configuration injection with @ConfigProperty in a ContextResolver are null unless class is annotated with @ApplicationScoped.

Expected behavior
Property should have the value defined in application.properties without additional configuration.

Actual behavior
Property value is null unless class is annotated with @ApplicationScoped.

To Reproduce
Steps to reproduce the behavior:

1. Create project and add JsonB configuration as

@Provider
public class JsonConfig implements ContextResolver<Jsonb> {

    @ConfigProperty(name = "json.date-format")
    String dateFormat;;

    @Override
    public Jsonb getContext(Class type) {
		System.out.println(dateFormat);
        final JsonbConfig config = new JsonbConfig()
            .withDateFormat(dateFormat, Locale.getDefault())
        return JsonbBuilder.create(config);
    }

}

2. Add json.date-format=yyyy-MM-dd'T'HH:mm:ss.SSSX to application properties.
3. Make a call to a service that returns a Json response.
4. Debug or check the println to see a null value.
5. Add @ApplicationScoped to class and repeat to see the value is not null.

Configuration
N/A

Screenshots
N/A

Environment (please complete the following information):
Quarkus version: 0.21.2
Extensions: [agroal, cdi, hibernate-orm, hibernate-validator, jdbc-postgresql, narayana-jta, resteasy, resteasy-jsonb, security, smallrye-jwt]

Maven home: /home/asalgadr/.sdkman/candidates/maven/current
Java version: 1.8.0_222, vendor: Oracle Corporation, runtime: /home/asalgadr/.sdkman/candidates/java/19.2.0-grl/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix"

Additional context
(Add any other context about the problem here.)

[gwenneg]

@abelsromero If you want this injection to work before 0.23.0 is released, you can try adding the javax.inject.Inject annotation to the dateFormat field.

[geoand]

@gwenneg any idea why it doesn't work in previous versions?
I would expect this to work since I thought @Provider classes were beans

[gwenneg]

@geoand It looks like there's a @BuildStep ordering issue here. AutoInjectFieldProcessor.annotationTransformer() is being run after ResteasyServerCommonProcessor.annotationTransformer() while I think it should be the opposite. Therefore, when the method that transforms @Provider into @Singleton is run, the @ConfigProperty-annotated fields are not annotated with @Inject yet.

I'm not sure of the best way to force the @BuildStep order though (I know about the general logic, I'm speaking of this specific case).

[gwenneg]

@geoand I've been looking for an existing BuildItem that could be produced by AutoInjectFieldProcessor.annotationTransformer() and then consumed by ResteasyServerCommonProcessor.annotationTransformer() to force the order, but I didn't find anything convincing :)

[geoand]

@gwenneg interesting. I haden't seen ResteasyServerCommonProcessor#annotationTransformer before but I'm wondering why that can't be replaced with a BeanDefiningAnnotation.
Unless I'm missing something, that would achieve the same result and also overcome the problem you describe

[mkouba]

@geoand I don't remember the details but it was something like that we don't register all providers found on the class path. See #1924 comments for more details.

@gwenneg So your solution is ok for @ConfigProperty but it wouldn't work for other annotations (CDI qualifiers in general). I'll try to modify the code and make use of AutoInjectAnnotationBuildItem.

[gwenneg]

@mkouba That's why I was looking for a better way to fix this than #4024 :) Could you ping me when you submit the PR? I'm interested in the way you'll improve this.

[abelsromero]

In case someone comes here looking for the TLDR.
Just updated to 0.23.1 and it works perfectly with only @Provider annotation.

[gwenneg]

Thanks for your feedback @abelsromero!