Provide dedicated ApplicationContext implementations for use with (JavaConfig) @Configuration classes [SPR-5682]

[spring-projects-issues]

Chris Beams opened SPR-5682 and commented

The JavaConfig project provided [JavaConfigApplicationContext](http://static.springframework.org/spring-javaconfig/docs/1.0.0.M4/javadoc-api/org/springframework/config/java/context/JavaConfigApplicationContext.html) and [JavaConfigWebApplicationContext](http://static.springframework.org/spring-javaconfig/docs/1.0.0.M4/javadoc-api/org/springframework/config/java/context/JavaConfigWebApplicationContext.html) to allow for eliminating XML entirely. (See also: usage).

Similar implementations could be provided in Spring Core, though naming would probably change to ConfigurationClassApplicationContext and ConfigurationClassWebApplicationContext, respectively.

There are a number of issues to consider and work out before providing this support, but this issue can serve as a way to track community interest.

---

Sub-tasks:

• Eliminate duplicate code between ConfigurationClassApplicationContext and ConfigurationClassWebApplicationContext [SPR-6186] #10854 Eliminate duplicate code between ConfigurationClassApplicationContext and ConfigurationClassWebApplicationContext
• Document @Configuration classes and AnnotationConfig[Web]ApplicationContext [SPR-6187] #10855 Document @Configuration classes and AnnotationConfig[Web]ApplicationContext

Issue Links:

• Support @ImportResource within @Configuration classes [SPR-6158] #10826 Support @ImportResource within @Configuration classes
• Provide TestContext support for @Configuration classes [SPR-6184] #10852 Provide TestContext support for @Configuration classes
• Support BeanFactory#getBean(Class<T> requiredType) [SPR-5529] #10200 Support BeanFactory#getBean(Class requiredType)

Referenced from: commits cbadf35, fd8935b, a48234c, 772a74a

12 votes, 13 watchers

[spring-projects-issues]

Juergen Hoeller commented

Current not-too-bad option, assuming annotated classes in "mypackage":

GenericApplicationContext context = new GenericApplicationContext();
ClassPathBeanDefinitionScanner scanner = new ClassPathBeanDefinitionScanner(context);
scanner.scan("mypackage");
context.refresh();

ConfigurationClassPostProcessor gets automated automatically... So this is actually about general classpath-scanning ApplicationContext convenience!

In the web case (as of 3.0 M3):

GenericWebApplicationContext context = new GenericWebApplicationContext(servletContext);
ClassPathBeanDefinitionScanner scanner = new ClassPathBeanDefinitionScanner(context);
scanner.scan("mypackage");
context.refresh();

The only thing we're missing is a ClassPathXmlApplicationContext / XmlWebApplicationContext equivalent. I'm not sure whether we should turn the Generic(Web)ApplicationContext model into more of a first-class feature, or rather build ClassPathScanningApplicationContext-style convenience classes...

Juergen

[spring-projects-issues]

Craig Walls commented

The option that Juergen offers is better than nothing, but it's not a one-for-one swap with what is available for the XML configuration option. The XML-haters may not be appeased if they have to do any more (even if it's a little more) than what you have to do for the XML configuration.

I'm in favor of including JavaConfigApplicationContext and JavaConfigWebApplicationContext in Spring 3. Just my $0.02.

[spring-projects-issues]

Juergen Hoeller commented

Assigning this to you, Chris - as per our discussion today, with the goal being inclusion of ConfigurationClassApplicationContext and co in Spring 3.0 RC1.

Juergen

[spring-projects-issues]

Gabriel Axel commented

Will it include the annotations-related features that were added to JavaConfig M4 (@AnnotationDrivenTx, @AnnotationDrivenTx, etc) ? It will be be very helpful to have them in the Spring core.

[spring-projects-issues]

Chris Beams commented

@Gabriel - not exactly, but equivalents will be provided; and if not immediately, within the Spring 3.1 timeframe. As for @AnnotationDrivenConfig, it is unnecessary as this behavior will be enabled by default when bootstrapping via the forthcoming ConfigurationClass[Web]ApplicationContext. @AnnotationDrivenTx will probably take a different shape in the short term. It is a problem to commit to these annotations, because the implication is that we will provide annotation-based equivalents for all the functionality currently provided by the various XML namespaces and their respective elements. For example, we would need to provide @MBeanExport, @OsgiService, @OsgiReference, etc, etc. This represents not only an ugly and ongoing duplication of efforts, but is also non-idiomatic Java. Simply said, using all these annotations ends up being a little too weird.

The general goal at this time is to provide programmatic access to the same APIs that underlie the XML namespaces themselves (search around for NamespaceHandler implementations within Spring Core). This requires a fair bit of refactoring of the NamespaceHandler API, and thus will not happen until Spring 3.1.

In the meantime, along with the new ConfigurationClassApplicationContext implementations, we will also commit @ImportXml, which will provide easy access to any XML features not (yet) directly supported by the @Configuration model (e.g.: <tx:annotation-driven/>).

[spring-projects-issues]

Chris Beams commented

Committed rev 2048: "SPR-5682: Initial support for ConfigurationClassApplicationContext"

https://fisheye.springsource.org/browse/spring-framework/trunk/org.springframework.context/src/main/java/org/springframework/context/annotation/ConfigurationClassApplicationContext.java?r=HEAD

[spring-projects-issues]

Chris Beams commented

Just added org.springframework.web.context.support.ConfigurationClassWebApplicationContext. A number of folks are watching this issue; any road tests and feedback would be most appreciated.

[spring-projects-issues]

Juergen Hoeller commented

FYI, I'm in the process of reworking CC(W)AC into general AnnotationConfigApplicationContext and AnnotationConfigWebApplicationContext implementations: supporting @Configuration classes but also plain @Components, with options for explicit registration of classes as well as for classpath scanning. Seems to work fine for @Configuration purposes still... and provides great convenience for the @Component model and the JSR-330 model as well, all of which are tied up nicely in Spring 3.0 now.

Juergen