fix(docs): propose a mapKey for generated config docs of a Map config item only for config group

[machi1990]

Fixes #4700

/cc @gsmet can you try this fix please? thanks.

[gsmet]

@machi1990 so I finally got to this one: I rebased and generated the doc but it doesn't work.

There are several elements with the same anchor in the KeycloakPolicyEnforcerConfig. I wonder if it's not the two maps at the bottom causing issues.

Could you have a look?

[machi1990]

@machi1990 so I finally got to this one: I rebased and generated the doc but it doesn't work.

There are several elements with the same anchor in the KeycloakPolicyEnforcerConfig. I wonder if it's not the two maps at the bottom causing issues.

Hi Guillaume, I think we the @ConfigItem(name = ConfigItem.PARENT) parent name, the two configs will end up with parent name/key i.e quarkus.keycloak.policy-enforcer."paths".claim-information-point.

What we can try to detect this configuration and fallback to not treating the keys as passthrough - we'll have something like this quarkus.keycloak.policy-enforcer."paths".claim-information-point."complex-config" and quarkus.keycloak.policy-enforcer."paths".claim-information-point."simple-config" WDYT? @gsmet

Also, the description on the two config items could use some love. If we display the two keys just like suggested above with a proper description - what is the complex config or a simple config and when to use one or the other, an example usage will be useful.

In the meantime we have empty java docs

        @ConfigGroup
        public static class ClaimInformationPointConfig {

            /**
             *
             */
            @ConfigItem(name = ConfigItem.PARENT)
            Map<String, Map<String, Map<String, String>>> complexConfig;

            /**
             *
             */
            @ConfigItem(name = ConfigItem.PARENT)
            Map<String, Map<String, String>> simpleConfig;
        }

WDYT ? @pedroigor @sberyozkin

[gsmet]

I hadn't followed this but you're right it looks very fishy.

[gsmet]

So... the config property is OK but... the type is not. In the MongoDB case I put in the original issue, you need the type to be Map<String, String> not String as it is now.

[machi1990]

@gsmet I just rebased with master. This one is ready for review now.

[gsmet]

OK, it fixes some very important issues with doc generation so let's merge it and backport it.

[gsmet]

Thanks @machi1990 !

[machi1990]

Thanks @machi1990 !

My pleasure :-)