Config Property name and value not derived when injection_point_name is a parameter name

[Joseph-Cass]

According to the following spec, a Config Property name will be derived from <class_name>.<injection_point_name> where <injection_point_name> can be a parameter name.

However, for the following Injections

@Inject
public aConstructor(@ConfigProperty String DEFINED_KEY1) {}

and

@Inject
public void aMethod(@ConfigProperty String DEFINED_KEY2) {}

where <class_name>.DEFINED_KEY1 and <class_name>.DEFINED_KEY2 are defined in a Config Source.

However, I'm getting the following errors:

java.lang.IllegalStateException: SRCFG02002: Could not find default name for @ConfigProperty InjectionPoint [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public <class_name>(@ConfigProperty)

and

java.lang.IllegalStateException: SRCFG02002: Could not find default name for @ConfigProperty InjectionPoint [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedMethod] @Inject public <class_name>.aMethod(@ConfigProperty String)

respectively.

Should this Injection be valid?

[radcortez]

No, because the parameter names may not be available over reflection. We could support it if we add a @Named annotation on each parameter.

[Emily-Jiang]

@radcortez if smallRye config does not support it, it does not comply with the spec. The spec clearly states the following:

/**
     * The key of the config property used to look up the configuration value.
     * <p>
     * If it is not specified, it will be derived automatically as {@code <class_name>.<injection_point_name>}, where
     * {@code injection_point_name} is the field name or parameter name, {@code class_name} is the fully qualified name
     * of the class being injected to.
     * <p>
     * If one of the {@code class_name} or {@code injection_point_name} cannot be determined, the value has to be
     * provided.
     *
     * @return Name (key) of the config property to inject
     */
    @Nonbinding
    String name() default "";

Having said that, I am not sure how useful it is for the name default. If it is not useful, we can update spec to make name parameter required instead. In this way, without name specified, DefinitationException should be thrown. Thoughts?

[Azquelt]

If one of the {@code class_name} or {@code injection_point_name} cannot be determined, the value has to be provided.

So if the parameter name can't be determined from the class file, I think that means the name value has to be provided.

That said, I don't think smallrye currently uses the parameter name if the user compiled with -parameters so that the parameter names are present.

I doubt that anyone is actually using a parameter name as the default at the moment, so I'd be happy to either remove it from the spec. If we don't, there should definitely be a TCK for it. We could just make the name required, but I'm not sure it's worth breaking backward compatibility for.

[radcortez]

I think we should remove parameter name as a valid source to retrieve the configuration name. It would just cause confusion if someone wants to use it and forgets about -parameters.

Using @Named will not be very different from using @ConfigProperty with the name set, so it is somehow redundant and no point to support it in my opinion.

[Emily-Jiang]

I am happy with the settlement of " for parameter injection, {@code injection_point_name} cannot be determined, the value has to be provided.". We can have this issue closed if we are in agreement. Thoughts?

[radcortez]

Should we clarify this in the spec?

[Emily-Jiang]

oops. I reread the javadoc, it is clearly saying the parameter name with class name would be used for the property name. It is better if this can be fixed in SmallRye. @radcortez under what circumstances you think the parameter name is not avilable via reflection?

[radcortez]

You need to explicitly add -parameters to the compiler to be able to get the parameter name via reflection. We can check if the parameter name is there and provide the injection, but I think in most cases no one is including the parameter names.

I don't remember seeing anyone complaining about this, so I think it is safe to say no one really used it before. I think we should drop this requirement.