Conditions evaluation report mistakenly prints '@ConditionalOnBean' for negative matches

[xak2000]

Conditions evaluation report wrongly reports @ConditionalOnMissingBean conditions as if it was @ConditionalOnBean condition for negative matches.

Example:

============================
CONDITIONS EVALUATION REPORT
============================

... skipped text ...

Negative matches:
-----------------

... skipped text ...

   UserDetailsServiceAutoConfiguration:
      Did not match:
         - @ConditionalOnBean (types: org.springframework.security.authentication.AuthenticationManager,org.springframework.security.authentication.AuthenticationProvider,org.springframework.security.core.userdetails.UserDetailsService,org.springframework.security.oauth2.jwt.JwtDecoder,org.springframework.security.oauth2.server.resource.introspection.OpaqueTokenIntrospector; SearchStrategy: all) found beans of type 'org.springframework.security.authentication.AuthenticationManager' authenticationManager and found beans of type 'org.springframework.security.core.userdetails.UserDetailsService' myUserDetailsService and found beans of type 'org.springframework.security.authentication.AuthenticationProvider' anonymousUserAuthenticationProvider, myAuthenticationProvider (OnBeanCondition)
      Matched:
         - @ConditionalOnClass found required class 'org.springframework.security.authentication.AuthenticationManager' (OnClassCondition)

Here, we see in the report Did not match: @ConditionalOnBean... where it is actually a report for @ConditionalOnMissingBean condition from UserDetailsServiceAutoConfiguration class.

So, it works right, but mistakenly prints @ConditionalOnBean instead of @ConditionalOnMissingBean.

---

Spring Boot 2.2.1.RELEASE

[wilkinsona]

Thanks for the report, @xak2000.

On first look, I suspect this is specific to the case where we have metadata for the auto-configuration class that allows it to be filtered out early:

spring-boot/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/condition/OnBeanCondition.java

Lines 82 to 99 in c3786e7

	@Override
	protected final ConditionOutcome[] getOutcomes(String[] autoConfigurationClasses,
	AutoConfigurationMetadata autoConfigurationMetadata) {
	ConditionOutcome[] outcomes = new ConditionOutcome[autoConfigurationClasses.length];
	for (int i = 0; i < outcomes.length; i++) {
	String autoConfigurationClass = autoConfigurationClasses[i];
	if (autoConfigurationClass != null) {
	Set<String> onBeanTypes = autoConfigurationMetadata.getSet(autoConfigurationClass, "ConditionalOnBean");
	outcomes[i] = getOutcome(onBeanTypes, ConditionalOnBean.class);
	if (outcomes[i] == null) {
	Set<String> onSingleCandidateTypes = autoConfigurationMetadata.getSet(autoConfigurationClass,
	"ConditionalOnSingleCandidate");
	outcomes[i] = getOutcome(onSingleCandidateTypes, ConditionalOnSingleCandidate.class);
	}
	}
	}
	return outcomes;
	}

[jcordoba95]

Hello! If no one else is working on this, I would like to work on this.

[wilkinsona]

That would be great, thank you @jcordoba95. Please let us know if you have any questions while working on it.

[OLPMO]

I made some debug and found that this bug is caused by a wrong construction of log information.
In getMatchOutcome of OnBeanCondition, the spec.message(ConditionalOnMissingBean.class).because(reason) would be called for constructing the log message.However,the constructor would only generate the log message of
org.springframework.boot.autoconfigure.condition.ConditionalOnBean

ConditionMessage.Builder message() {
	return ConditionMessage.forCondition(ConditionalOnBean.class, this);
}

So, my solution is that pass the info of class to the ConditionMessage.Builder message() in order to construct the correct log . Like this

ConditionMessage.Builder message(Class<? extends Annotation> clazz) {
	return ConditionMessage.forCondition(clazz, this);
}

Is my idea correct? Besides, I want to ask where is the test function of org.springframework.boot.autoconfigure.condition.OnBeanCondition.Spec#message(java.lang.Class<? extends java.lang.annotation.Annotation>)? @wilkinsona

[wilkinsona]

Thanks for taking a look, @OLPMO, but @jcordoba95 is already working on this issue.

[OLPMO]

OK, I hope to contribute code to the project next time.Thanks for your reply.@wilkinsona

[jcordoba95]

Realized this was set for milestone 2.1.X, so I closed my pull request since the solution I wrote was according to what OLPMO found (and realized the file has changes and the solution won’t work for this milestone).

@wilkinsona I do have a question, how can I replicate this issue to make some debugging? I could't find any replication steps.

[wilkinsona]

@jcordoba95 I don't believe we have any. @xak2000 Could you provide a small sample the reproduces that behaviour you've described?