PropertySourcesPropertyValues glitch with CompositePropertySource

[konrad-garus]

PropertySourcesPropertyValues.processPropertySource does the following:

private void processPropertySource(PropertySource<?> source,
        PropertySourcesPropertyResolver resolver,
        PropertyNamePatternsMatcher includes, Collection<String> exacts) {
    if (source instanceof EnumerablePropertySource) {
        processEnumerablePropertySource((EnumerablePropertySource<?>) source,
                resolver, includes, exacts);
    }
    else if (source instanceof CompositePropertySource) {
        processCompositePropertySource((CompositePropertySource) source, resolver,
                includes, exacts);
    }
    else {
        // We can only do exact matches for non-enumerable property names, but
        // that's better than nothing...
        processDefaultPropertySource(source, resolver, includes, exacts);
    }
}

Since Spring 4.1.2, CompositePropertySource extends EnumerablePropertySource.

There are two issues with it:

1. The second branch of the condition (first "else") is never executed (dead code).
2. CompositePropertySource does not actually fulfil the specification of EnumerablePropertySource. It may contain a non-enumerable property source in which case getPropertyNames does not in fact list all the properties.

The latter is arguably an issue in Spring core. But it has negative effect on Spring Boot as well, so it probably should be fixed in the core or worked around in Boot.

[konrad-garus]

Bug report in core: https://jira.spring.io/browse/SPR-12788

[jhoeller]

So I suppose flipping Boot's instanceof cascade to check for CompositePropertySource first would fix the immediate problem here?

[konrad-garus]

@jhoeller Yes, it seems like it would be a good workaround for that core glitch here in Boot.