A nice write up, and I’m glad to hear you like what you’re seeing. I thought I’d take a moment to address your questions and concerns:

> Explicit bean declaration and DI vs. full component-scanning, vs. a mix of bean declaration and dependency autowiring:

I’ll just speak from the experience that I and other SpringSource consultants have seen with real teams using Spring ‘in the wild’. While explicit XML-based configuration is still very common, a large percentage of teams have taken to using component scanning liberally throughout their applications. This does require a bit of educating the team as to how it works, but what doesn’t? The productivity benefits gained from not needing to return to the XML for every change seem to outweigh the initial and very short learning curve. Making proper use of the @Service, @Repository annotations (as you did above) helps in this process. The team gets to know what these annotations mean rather quickly. I wouldn’t underestimate developers too much.

I would generally advise against the third option you mention, of defining the bean definition explicitly, but allowing dependencies to be autowired. This is a kind of ‘one foot in, one foot out’ approach, and comes off a little bit like false advertising. I find it the most confusing personally, and have heard the same sentiments in teams I’ve consulted with. I have actually never seen a serious application use this mix of explicit declaration and autowiring as a team standard.

Now, keep in mind that even if one agressively adopts component scanning and use of @Autowired, there is still, by necessity, a place for explicit bean declaration and wiring. Any time you’re dealing with a third party class (usually infrastructure-related, such as a DataSource), you of course must declare this explicitly in XML (or JavaConfig).

This sums up the best practice that I see with teams using Spring in a modern fashion: Explicit wiring for infrastructure (JMS, JDBC, etc), and component-scan/@Autowired for the service and data access layers.

> Component-scanning issues in Java EE application servers:

Spring’s component scanning facility is pretty solid. I know of no open issues around classloading problems in Java EE environments. Using component scanning in an OSGi environment is more tricky, but even those problems have all been addressed in Spring DM and dm Server.

> Future of JavaConfig

As you mentioned, essential JavaConfig functionality has been ported to Spring Core for the 3.0M3 release. Although 3.0M3 has not yet dropped, the current phase of the porting effort is complete. I’d love it if you’d take a look and provide feedback on what you see.

You can grab the latest nightly build snapshot of Spring 3.0 using Maven: http://pastebin.com/f472b1c7d. Explore the org.springframework.context.annotation package to see what’s there / what’s new. You’ll see the familiar @Configuration, @Bean and @Import annotations; also you’ll see that @Scope has been updated for use with @Bean methods, and there are also now @Lazy, @Primary and @DependsOn annotations that are usable with @Bean methods or at the class level in conjunction with @Component.

You’ll notice that certain annotations and classes have not been ported, such as JavaConfig[Web]ApplicationContext, @ComponentScan, @AnnotationDrivenConfig and others.

Right now, in an effort to keep things as minimal as possible, the ‘bootstrapping mechanism’ for JavaConfig is XML. You can have a very minimal XML file such as this one: http://pastebin.com/f76cd1c59

There is an existing issue against Spring 3 to port the JavaConfig ApplicationContext implementations. You may want to watch/vote/comment on that issue to stay tuned: http://jira.springframework.org/browse/SPR-5682

> Compatibility issues between JavaConfig 1.0.0.M4 and Spring 3.0M2

Note that these issues have been worked out in the forthcoming Spring 3.0M3, so it’s actually possible now to us JavaConfig 1.0.0.M4 against the nightly snapshots mentioned above. This usage is mutually exclusive with the new functionality that’s been ported into core, but you can use one or the other per your choice.

Again, all feedback is welcome, and thanks for your interest!

Chris Beams
Lead, Spring JavaConfig
http://springsource.org/javaconfig
twitter: @cbeams, @javaconfig