Vertx Logger and ConfigProperties was deprecated

[pjgg]

Upgrade deprecated code:

io.quarkus.arc.config.ConfigProperties was deprecated
Vertx Logger was deprecated

[pjgg]

Looks like io.smallrye.config.ConfigMapping doesn't behaves exactly the same as the deprecated io.quarkus.arc.config.ConfigProperties.

ConfigProperties is able to read child properties from a parent class configuration:
Example:

@ConfigProperties(prefix = "antagonist")
public class AntagonistConfiguration {
    public String message;
    public String name;
    public AntagonistWifeConfig wife;

    public static class AntagonistWifeConfig {
        public String name;
        public String message;
    }
}

application.properties

antagonist.name=Sheldon Plankton
antagonist.message=Hi, I am Sheldon Plankton
antagonist.wife.name=Karen
antagonist.wife.message=Hi, I am Karen

But the same scenario with ConfigMapping throw an exception

SRCFG00013: No Converter registered for class io.quarkus.qe.config.AntagonistConfiguration$AntagonistWifeConfig

[rsvoboda]

@pjgg this is candidate for a bug report. The transition should be smooth for the users.

[pjgg]

@pjgg this is candidate for a bug report. The transition should be smooth for the users.

Issue: quarkusio/quarkus#17545
Issue: quarkusio/quarkus#17588

[jsmrcka]

What is the plan with the different behavior of @ConfigMapping? (See quarkusio/quarkus#17545 (comment), which corresponds with https://smallrye.io/docs/smallrye-config/main/mapping/mapping.html, also referenced in https://quarkus.io/version/main/guides/config#inject-the-configuration.)

I see no way to smoothly transition from the deprecated annotation.

[pjgg]

What is the plan with the different behavior of @ConfigMapping? (See quarkusio/quarkus#17545 (comment), which corresponds with https://smallrye.io/docs/smallrye-config/main/mapping/mapping.html, also referenced in https://quarkus.io/version/main/guides/config#inject-the-configuration.)

I see no way to smoothly transition from the deprecated annotation.

The new implementation is great!. To me makes even more sense than the old one from a conceptual point of view.

For example the above code will look something like this:

@ConfigMapping(prefix = "antagonist")
public interface AntagonistConfiguration {
     String message();
     String name();
     AntagonistWifeConfig wife();

    public interface AntagonistWifeConfig {
        String name();
        String message();
    }
}

But the point is that this change is a breaking change that will makes fail all the existing applications that use this feature. So, we should think about a smooth transition.