@bnasslahsen @zakaria-shahen IMHO #3131 makes deep sense.
The idea of the current issue is to prevent default IMPLICIT insecure configuration to go live without attention.

However if a developer needs this API and enables it EXPLICITLY - the warning becomes just confusing.

+1, these warnings are currently unconditionally printed if the docs are enabled, it doesn't make sense at all to have unfixable warnings.

There should be a way to disable the warnings, and that would be explicitly enabling the docs.

@Gugu7264/ @zakaria-shahen / @lrozenblyum,

As you can see, it's not easy to satisfy everyone in the open source community!
To accommodate your preference as well, I suggest we introduce an additional property to disable the warnings.
Even, it just adds more configuration...

You're welcome to submit a new PR for this change!

Yes, I agree with @bnasslahsen that adding more configuration options can be misleading or confusing to users. Perhaps in the next major version, we could do a similar revamp of the configuration properties like what the Spring team did in Spring Boot 2.0.

For example, we could deprecate the following properties:

• springdoc.api-docs.enabled
• springdoc.swagger-ui.enabled
• scalar.enabled

And replace them with a single property: springdoc.enabled=scalar,swagger-ui,api-docs, with the default value set to none.

@bnasslahsen @zakaria-shahen Instead of adding a new property, couldn't we just display the warnings if the corresponding property (springdoc.[api-docs/swagger-ui].enabled) is not set?

That would make sense to have the warnings in such a case, and also would prevent having yet another property to add as you said.

@Gugu7264,

I vote for it. I think that could also make sense.
However, it raises the question of whether it would cover all use cases.
There will always be someone asking for a different behavior or level of control, so relying solely on the absence of a property might not be flexible enough for everyone.

@bnasslahsen I see your point, but it would be more confusing to have a property just to disable a warning.
In any case relying on the absence of a property is better than an unconditionally raising a warning.

Agree, we will go for it for now, and see feedbacks

I just stumbled upon this discussion, because I was trying to get rid of the warnings in some projects.
I can confirm that my initial expectation before searching here was to get rid of it by setting the property explicitly, as suggested by @Gugu7264 .

I just stumbled upon this discussion, because I was trying to get rid of the warnings in some projects. I can confirm that my initial expectation before searching here was to get rid of it by setting the property explicitly, as suggested by @Gugu7264 .

I had the very same journey and consider @Gugu7264 suggestion a good first start. 👍