It definitely does make the above more manageable, but it doesn't solve the core problem which is that the whole design pattern is built for complete configurability, but without sensible defaults. In some sense, Spring only exists to manage the massive configurability of Java design patterns, but by adding it's own configurations to the mix. It's definitely a cool idea, but the better solution is to just avoid factory/context patterns. It's solving a problem most of us don't have.
"""It's solving a problem most of us don't have."""
I think that is because a lot of people simply don't know what good design is. I've seen many projects where people think they don't need Spring but where it made 100% sense. And made the project simpler and easier to manage and test.
Even in small projects it makes a lot of sense to have a good seperation in layers or services and to use a mostly invisible helper to glue things together.
Modern Spring can configure your app with a very minimal amount of XML. If you don't like XML then use annotation based configuration.
I totally disagree with your statement that Spring only exists to manage the 'massive configurability of Java design patterns'. The only patterns that the foundation of Spring introduces are IoC and 'configuration by convention'. Those have been proven to be extremely powerful patterns that simply allow you to burn half of the 'J2EE Design Patterns' books.
