Add userParameterMode = CUSTOM for selecting a custom type for authentication in servers

[giovanniberti]

Closes #2562

[cla-assistant]

All committers have signed the CLA.

[altro3]

@giovanniberti need to sign CLA

[altro3]

@giovanniberti ping

[giovanniberti]

Sorry for the delay! :)
Btw, after removing the FIXME I think the PR will be ready to be merged, I'll also probably write a follow-up PR to allow customizing the name of the generated auth parameter

[altro3]

Sorry for the delay! :) Btw, after removing the FIXME I think the PR will be ready to be merged, I'll also probably write a follow-up PR to allow customizing the name of the generated auth parameter

Ok! I'm ready to merge this PR. Waiting your fix

[giovanniberti]

Added checks and tests for the combination of userParameterMode and userParameterClass, as soon as the pipeline goes green you can merge 🚀

[altro3]

@giovanniberti run gradle spotlessApply to fix this problem and commit again

[giovanniberti]

Done

[altro3]

@giovanniberti you need to run build locally before commit.

Some tests failed:

KotlinMicronautServerCodegenTest.testEnumNullable()
JavaMicronautServerCodegenTest.testEnumNullable()

[altro3]

There is your mistake: you need to check this parameter only when userModeOpt == CUSTOM

[giovanniberti]

That's the point of the check, we have four possible cases:

• userParameterMode == CUSTOM
  • and userParameterClass not set -> user error, covered by the first check
  • and userParameterClass set -> ok
• userParameterMode != CUSTOM
  • and userParameterClass not set -> ok
  • and userParameterClass set -> user error, covered by the else if

One parameter without the other is not a configuration that makes sense to support.

The problem at the implementation level was that additionalProperties.contains(OPT_USER_PARAMETER_CLASS) evaluates to true because there are other parts of the code that populate the map with that key and set null as the value if the user doesn't provide it.

Does it make sense to you?

[altro3]

Yes, of course, I understand that we have four possible combinations.

But in my opinion, it would be easier to simply ignore the userParameterClass parameter if the mode is different from CUSTOM, rather than throwing an error. Because here you're already checking for the mode.

So, now you're checking the mode at startup, and then checking the mode every time you substitute the class.

[altro3]

The main idea is that if a user switches the mode via a gradle plugin, so that his build doesn't break due to the fact that he has specified a parameter userParameterClass that is used only in CUSTOM mode, but simply silently ignore this parameter

[giovanniberti]

Personally I don't like inferring the correct configuration via precedence rules, but if that's the convention in Gradle or specifically in this plugin I'll remove the extra check

[altro3]

This is a small thing, in my opinion. That's okay too

[giovanniberti]

you need to run build locally before commit

Weird, I did, something must have broken Gradle's config on my IDE 🤔

EDIT: I'm getting test failures (specifically a NullPointerException on :test-suite-server-generator-kotlin-kapt:generateOpenApi) on the unmodified 6.19.x branch (commit 51ae01d), I'll use the pipelines as the reference for green tests if you're ok with it

[giovanniberti]

Given the open discussion and my current setup limitations I'm leaving this PR in draft for the moment until you're ok with it moving forward