SB 3.4.0 management endpoints properties migration doesn't seem work properly

[francisco-bru]

I'm migrating to 3.4.0 version and I apreciate that management.endpoints.enable-by-default and management.endpoint.id.enabled are deprecated as it says in the release notes.

In these release notes it appears that there are 3 values for the new access properties: none, read-only and unrestricted. However, in the release documentation, the ‘disabled’ is indicated, but disabled is not a valid value:

Caused by: java.lang.IllegalArgumentException: No enum constant org.springframework.boot.actuate.endpoint.Access.disabled

In my application I have an endpoint running with the following configuration:

management.endpoints.enabled-by-default=false
management.endpoint.foo.enabled=true

However when migrating to version 3.4 this endpoint is no longer exposed.
I thought that being deprecated properties and not deleted, I should not make changes yet.
Anyway I have made the following changes:

management.endpoints.access.default=none
management.endpoint.foo.access=unrestricted

and the enpoint is still not exposed.
I have only been able to expose it with the following configuration:

management.endpoints.access.default=unrestricted

But, this is not the correct behaivor.

[wilkinsona]

However, in the release documentation, the ‘disabled’ is indicated, but disabled is not a valid value

Sorry, that's a mistake in the docs. It should be none rather than disabled. We'll correct it.

I can't reproduce the runtime behavior that you have described. For example, these properties work for me:

management.endpoints.web.exposure.include=*
management.endpoints.enabled-by-default=false
management.endpoint.foo.enabled=true

The foo endpoint is the only endpoint that's available.

These properties also work for me:

management.endpoints.web.exposure.include=*
management.endpoints.access.default=none
management.endpoint.foo.access=unrestricted

I've tested both with @ConditionalOnAvailableEndpoint and without and the behavior's the same.

If you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.