getBean(Object.class) fails when introspecting Environment bean [SPR-10542]

[spring-projects-issues]

James Shaw opened SPR-10542 and commented

Trying to access a bean of type Object gives the backtrace:

Exception in thread "main" org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'environment' is defined
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:568)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:264)
	at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1125)
	at Test.main(Test.java:7)

See attached test case to reproduce.

---

Affects: 3.2.2

Attachments:

• spring-testcase.tar.gz (7.54 kB)

Issue Links:

• ApplicationContext fails to load in TestNG test if previous test is annotated with @DirtiesContext [SPR-12918] #17517 ApplicationContext fails to load in TestNG test if previous test is annotated with @DirtiesContext

Referenced from: commits 9d3d6d5, e89f18b, 21d0ce5

Backported to: 4.0.7, 3.2.11

[spring-projects-issues]

Phil Webb commented

There are several internal infrastructure beans registered by default with the context so calling applicationContext.getBean(Object.class) does not make much sense (but admittedly the error message is not great).

What are you trying to achieve with this call?

[spring-projects-issues]

James Shaw commented

If I remember correctly, I was writing an integration test where the contents of the ApplicationContext were unimportant. I admit that I can't think of terribly many use cases for this ;)

[spring-projects-issues]

Juergen Hoeller commented

Even if this is an unlikely use case, getBean(Class) needs to be able to handle singletons beans without a backing bean definition as well, if they turn out to be a type match...

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Fixed for 4.1 GA through an additional containsBeanDefinition check, leading to a proper NoUniqueBeanDefinitionException. To be backported to 4.0.7 and 3.2.11 as well.

Juergen