Consider replacing AuthorizationGrantType and ClientAuthenticationMethod

[philwebb]

We could replace our own AuthorizationGrantType and ClientAuthenticationMethod enums with Spring Security classes and use custom meta-data for hints.

[snicoll]

Can you explain why you've created those enums in the first place because I meant to ask and forgot.

Two things:

1. There are no meta-data required for enums. As long as the IDE is able to see the class, it should provide value auto-completion for it. If the source of the enum is available, it should attempt to display the documentation (so that's important the enum's javadoc as something consistent with the way we document things if possible)
2. There is no meta-data for Map-based key. So even if this was necessary it wouldn't be possible right now. We need bot a breaking change in the format of the key (possibly) and an update of all IDEs support to make that happen. I am quite sad that the provider property has no auto-completion for the providers we know. The hints section has all that's required for it but we can't write a hint for a property that's referenced via a map.

[mbhave]

@snicoll The enums were originally added for meta-data. But if I understood what you said correctly, generating meta-data or a hint for keys in a map is not possible today. So even if we removed the enums, it wouldn't be possible to add custom meta-data to get hints in this case?

[snicoll]

I am not sure that accurately describes what I meant.

Enums don't need metadata, they are processed by the IDE. So if you have a 100% matching enum in Spring Security, use that.

Yes, we can't add hints for something that's bound to a map or a list in the hierarchy.

[philwebb]

I think I see the confusion. The versions in Spring Security are not enums. They're regular classes with a few static final constants that you can use if you want.

In Spring Security you can do:

AuthorizationGrantType.AUTHORIZATION_CODE, but you can also do new AuthorizationGrantType("something-else").

[mbhave]

Enums don't need metadata

@snicoll I'm still slightly unsure what that means for enums that are used as values in maps.
I replaced the enums with the Spring Security classes. If anyone thinks we need to keep the enums, please feel to reopen.

[snicoll]

Nothing specific. Enums don't need metadata. Ever.

Perhaps the confusing part is that what I mean here is that you'll get auto-completion for enums regardless where it's defined (maps or non maps). That change however broke the meta-data as you no longer have auto-completion.

You can test it by using the key in your IDE. Can we restore proper meta-data for those keys please? Or do we want to support arbitrary values for those?

[mbhave]

I'm on the fence about that. Spring Security supports arbitrary values although BASIC and POST seem like the most common ones. Maybe we should support arbitrary values too.

[philwebb]

In this case I think we should forgo the IDE support in favor of matching what Spring Security does. If we stick with the enum there's no way for the user to pick anything other than BASIC and POST.

Once #9945 is fixed we can retrofit meta-data to give IDE hints.

It's also worth considering that most users will hopefully be using one of the common providers and will only need to venture into custom configuration very occasionally.