spring-cloud / spring-cloud/spring-cloud-consul

ConsulConfigProperties#getAclToken() remains null although spring.cloud.consul.token is available in the Environment

Open
#996 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

waiting-for-triage
Dominant language
Java
Stars
822
Forks
539
Avg merge
9h 31m
Merged PRs (30d)
7

Description

Description

I'm investigating the behavior of ConsulConfigProperties#getAclToken() in Spring Cloud Consul and I'm not sure whether this is an intended behavior or a bug.

In my application, spring.cloud.consul.token is successfully loaded from Spring Cloud Vault through ConfigData.

The property is available in the Environment, and a regular @Value("${spring.cloud.consul.token}") injection works correctly.

However, ConsulConfigProperties#getAclToken() always returns null.

Versions

  • Spring Boot: 3.5.14
  • Spring Cloud Release Train: 2025.0.1
  • spring-cloud-consul-config: 4.3.1

Configuration

spring:
  config:
    import:
      - vault://
      - consul://

  cloud:
    consul:
      config:
        enabled: true

The Consul ACL token is stored in Vault under:

spring.cloud.consul.token

Observations

The following values are logged during application startup:

Environment.getProperty("spring.cloud.consul.token")
=> 08****35 (masked intentionally)

ConsulConfigProperties#getAclToken()
=> null

The property source owning the property is:

dev-secret/consul-configs

Additional verification

To make sure this was not a configuration issue, I performed the following checks:

  • Environment.getProperty("spring.cloud.consul.token") returns the expected value.
  • A regular Spring bean using
@Value("${spring.cloud.consul.token}")
private String token;

receives the correct value.

  • ConsulConfigProperties itself is properly bound:

    • enabled
    • defaultContext
    • prefixes

    all contain the expected values.

  • Using reflection confirms that the internal aclToken field is still null.

Field field = ConsulConfigProperties.class.getDeclaredField("aclToken");
field.setAccessible(true);

System.out.println(field.get(consulConfigProperties));
// null

The field is annotated with:

@Value("${consul.token:${CONSUL_TOKEN:${spring.cloud.consul.token:${SPRING_CLOUD_CONSUL_TOKEN:}}}}")
private String aclToken;

and the annotation is present at runtime.

Question

Is this expected?

Should ConsulConfigProperties#getAclToken() be populated from spring.cloud.consul.token, or is the aclToken field intentionally left unset when using ConfigData (Vault)?

If it is expected to be populated, this appears to be a regression because:

  • the property exists in the Environment,
  • @Value works on regular Spring beans,
  • only the aclToken field inside ConsulConfigProperties remains null.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with ConsulConfigProperties and the aclToken field shown in the issue, then trace how its @Value expression is resolved when the property comes from a ConfigData Vault source. Compare that path with Environment.getProperty and regular @Value injection; done means establishing whether the null value is expected or reproducing a regression with focused coverage.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, spring-boot
Domain
backend, cloud
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.