I've read plenty of bashing of Spring's XML configuration lately. I have written my fair share of Spring XML and I can understand the concerns. I can't say that I've felt the same pain that the complainers have felt, but I do understand their concerns.
I don't find the XML configuration any more verbose or harder to read than some of the Java-based configuration options. Annotations are nice, but throw enough of those on a method or a class and it becomes a jumbled mess, too.
Refactoring and string identifiers is a more valid concern, but it isn't really an issue for me, as I'm using the latest and greatest SpringIDE in Eclipse (really awesome plugin, btw). Yeah, I'm leaning on a tool to help me with this, but so is everyone else when they lean on their IDE to refactor Java code (try refactoring a method name with notepad if you don't believe me).
Nevertheless, I understand the concerns. I understand how some folks don't like putting their configuration separate from their code and how others have complaints about string identifiers in Spring not being refactorable. I get it. I still use XML to wire up my beans in Spring. But I understand why others are uneasy with it.
But did you know that XML is not the only way to configure Spring? I know that I've already mentioned it at least once on this blog. But with the recent Spring XML sucks noise in blogspace, I feel that it bears repeating.
As a reminder, Spring has always been able to support multiple configuration options. XML just happens to be the "standard" out of the box way to configure it. But there are plenty alternatives, none of which are XML-based:
That list has no less than three annotation-based options (four if you count my own simplistic approach), one pure Java/no-annotations option, and a couple of script-based options. I especially like Spring JavaConfig as it brings Spring configuration directly into Java with annotations and without string identifiers. And I'm starting to think to find appeal in the scripting language options.
But if none of these strikes your fancy, then it's really not too difficult to extend Spring to support custom configuration options. In fact, the first thing I thought when I saw Guice was that it probably wouldn't be too difficult to build a Guice-like configuration on top of Spring's already established container, either by extending the container or through a post-processor. (I've not thought it through in detail, though.)
(And I'm still waiting for someone to build a YAML configuration for Spring.)
I will grant that none of these options has become mainstream and you don't see too much talk about them. I'm doing my part to let everyone know that they exist...if one of them looks promising to you, please give it a try and blog about it. But rather than gripe about how Spring sucks because its XML sucks, give one of these alternate configuration styles a spin.
P.S. If anyone knows about a Spring config option that I've not listed here, please let me know.
