Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@ConditionalOnProperty for branch of values not match #41621

Closed
lowcasz opened this issue Jul 25, 2024 · 3 comments
Closed

@ConditionalOnProperty for branch of values not match #41621

lowcasz opened this issue Jul 25, 2024 · 3 comments
Labels
status: declined A suggestion or change that we don't feel we should currently apply

Comments

@lowcasz
Copy link

lowcasz commented Jul 25, 2024

A have sample yaml property file:

prefix:
  branch1:
    branch2conditioned:
      branch3a:
        value: true
      barnch3b:
        value: false

I want use @ConditionalOnProperty and create bean when branch2conditioned is defined in application.
It does not work actually.

I tried:
'''
@ConditionalOnProperty("prefix.branch1.branch2conditioned")
@ConditionalOnProperty(prefix ="prefix.branch1", name="branch2conditioned")
@ConditionalOnProperty(prefix ="prefix.branch1.branch2conditioned")
'''
Neither condition match.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jul 25, 2024
@wilkinsona
Copy link
Member

Your YAML file above has defined two properties:

  • prefix.branch1.branch2conditioned.branch3a.value
  • prefix.branch1.branch2conditioned.branch3b.value

prefix.branch1.branch2conditioned doesn't exist as a property so it isn't matched.

If you want a condition that matches when any property whose name begins with prefix.branch1.branch2conditioned has been defined, you'll have to write your own Conditional implementation. It would have to examine all of the properties in the environment to see if any of them begin with prefix.branch1.branch2conditioned. Note that this will be imperfect as some PropertySources in the environment do not extend EnumerablePropertySource which means that they cannot list all of their properties. As such, your condition may not match when it should have done. This might not be a problem in your specific case as it will depend on the property sources that your application uses. JNDI is perhaps the most commonly used non-enumerable source.

@wilkinsona wilkinsona closed this as not planned Won't fix, can't repro, duplicate, stale Jul 26, 2024
@wilkinsona wilkinsona added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged labels Jul 26, 2024
@lowcasz
Copy link
Author

lowcasz commented Jul 26, 2024

Actually @ConditionalOnProperty(prefix ="prefix.branch1.branch2conditioned") generates exception due to missing name/value. I think it is great and intuitive place to add extra logic for the case when we have Map<String, ?> in property.
I would like to add this, because it is a common case and at first I thought it was a bug when I am able to map a property to a map.

Mapping to map can be usefull.
For simple example I have done it in this way:

public class PropertiesMapCondition implements Condition {

    private static final String property = "prefix.branch1.branch2conditioned";

    @Override
    public boolean matches(ConditionContext context, @Nullable AnnotatedTypeMetadata metadata) {
        return Binder.get(context.getEnvironment()).bind(property, HashMap.class).isBound();
    }

}

@wilkinsona
Copy link
Member

Actually @ConditionalOnProperty(prefix ="prefix.branch1.branch2conditioned") generates exception due to missing name/value

Yes, that's to be expected. I didn't say otherwise above.

When you bind properties to a map, the "property" that you're binding is actually the prefix. It's the keys that are added to the map that are the properties.

I still don't think this is generally useful and has a number of limitations as explained above. As such, it's better suited to a custom condition in your application where you can accommodate any limitations more easily. We can reconsider in the future if things change or there's significant demand for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

3 participants