Support of nested classes for bulk properties

[kshpak]

Description
Add support of nested classes for java class annotated with @ConfigProperties (like it's done for nested interfaces)

E.x.

@ConfigProperties(prefix = "user")
public class UserConfiguration {
    public String message;
    public String name;

    public UserConfigurationAdditions request;
     
       public static class UserConfigurationAdditions {
         public String min;
         public String max;
     }
}

[radcortez]

Hi @kshpak, thanks for reaching out.

When you refer to nested interfaces, I guess you mean the SmallRye Config @ConfigMapping with interfaces?

What do you need to achieve with classes that you are unable to achieve with interfaces?

[kshpak]

Hi @radcortez,
here is an example of mentioned nested interfaces

@ConfigProperties(prefix = "user")
public interface UserConfiguration {
    String name();
    String message();

    UserConfigurationAdditions request();

    interface UserConfigurationAdditions {
        String min();
        String max();
    }
}

Pretty everything can be achieved through interfaces, it's just another option of configuring properties through classes. Mentioned in the description option was present in quarkus.arc library. Now deprecated, because @ConfigProperties annotation was introduced in MicroProfile Config 2.0.

As @ConfigProperties can still be used with classes, the nested configuration is just a good complement

[radcortez]

Actually, Quarkus @ConfigProperties was deprecated in favour of SR Config @ConfigMapping which uses interfaces instead, not for MP Config @ConfigProperties.

In my opinion, the MP Config @ConfigProperties class support was a mistake. From the experience we had, supporting classes adds way more complexity for little gain (fields visibility, reflection, types defaults values). Please check the additional discussion here: smallrye/smallrye-config#310.

I believe that MP Config specification should review this, move to interfaces and of course support nested elements. I also believe the the specification shouldn't offer both flavours (less is more :)), but of course implementations are free to do it if they want.

[Emily-Jiang]

The class support for @ConfigProperties was to cater for the migration issues from Spring Config, which uses @ConfigProprties on classes. However, we can review this to see whether we should support on interfaces as well as classes or deprecate classes with prefering interfaces.