Improve exception message: Default SmartContextLoaders do not support locations and @Configuration classes simultaneously [SPR-12060]

[spring-projects-issues]

Stephane Mikaty opened SPR-12060 and commented

Overview

I'm still getting the error mentioned in the reference URL, and I have not found any other mention of this edge case. Is this by design or simply not implemented yet?

I attached the files I used as reproduction.

1. demo.notworking exhibits the issue
2. demo.working works as expected and so I think Spring core JMS pom.xml #1 could well be supported with a simple code fix.

When running demo.notworking.ConcreteSubTest as JUnit Test, I get the following:

java.lang.IllegalStateException: Neither GenericXmlContextLoader nor AnnotationConfigContextLoader was able to load an ApplicationContext from [MergedContextConfiguration@7e02286 testClass = ConcreteSubTest, locations = '{classpath:/test-config.xml}', classes = '{class demo.notworking.ConcreteSubTest$Config}', contextInitializerClasses = '[]', activeProfiles = '{}', contextLoader = 'org.springframework.test.context.support.DelegatingSmartContextLoader', parent = [null]].

When running demo.working.ConcreteSubTest as JUnit Test, I get the following:

org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type [demo.StringLabelBean] is defined: expected single matching bean but found 2: demo.StringLabelBean#0,bean

---

Deliverables

1. Improve exception message in AbstractDelegatingSmartContextLoader.loadContext() to provide better clarity in scenarios like the one described above.

---

Affects: 3.2.6, 3.2.10, 4.0.6

Reference URL: http://forum.spring.io/forum/spring-projects/container/125452-contextconfiguration-inheritance-mixing-xml-and-bean-configuration-in-spring-tests

Attachments:

• testfiles.tgz (1.17 kB)

Referenced from: commits 181299c

[spring-projects-issues]

Sam Brannen commented

This is by design.

For a given ApplicationContext that is loaded by one of the built-in context loaders in the Spring TestContext Framework you either have to use only path-based resources (via the value or locations attributes of @ContextConfiguration) or only annotated classes (via the classes attribute of @ContextConfiguration).

If you configure both locations and classes (and don't declare an ApplicationContextInitializer), you see the exception you mentioned.

However, just because the default (out-of-the-box) loaders don't support XML config and @Configuration classes at the same time, it doesn't mean it's not possible. Since Spring Framework 4.0.4, it is actually possible for a context loader to support multiple resource types. For example, Spring Boot supports multiple resource types simultaneously (e.g., XML, @Configuration classes, and Groovy scripts).

It's also quite easy to implement such a hybrid SmartContextLoader yourself. See HybridContextLoader for an example.

Regards,

Sam

[spring-projects-issues]

Sam Brannen commented

Reopening in order to improve the exception message (see Deliverables).

[spring-projects-issues]

Sam Brannen commented

Resolved as described in the comments for GitHub commit 181299c:

Improve ex msg when locations & classes are declared in test hierarchy

Prior to this commit, if both locations and classes were declared via
@ContextConfiguration at differing levels in a test class hierarchy,
the exception message stated that neither of the default context
loaders was able to load an ApplicationContext from the merged context
configuration, but the message didn't explain why.

This commit adds an explicit check for such scenarios and provides a
more informative exception message similar to the following:

"Neither X nor Y supports loading an ApplicationContext from
[MergedContextConfiguration ...]: declare either 'locations' or
'classes' but not both."