I have been reading Rod & Juergen's excellent "Expert One-on-One J2EE Development without EJB" lately, studying Spring as I go. I must say I'm quite impressed with Spring so far. At last a framework where 'm thinking: these people really put some thought into this.
However, there are some things that make me frown:
1) Complex inheritance hierarchies.
I keep running into the fact that the Spring source code has some very intricate class and interface inheritance hierarchies. Take the XmlBeanFactory for instance (look at the JavaDoc). I would say this is a pretty basic class in the framework. Yet, it implements no less than 7 (!) interfaces and is 4 levels deep in the class inheritance tree! This might bring ultimate flexibility for all possible situations, but I'm wondering whether this is not a case of YAGNI. Also, it makes things more complicated for users of the framework. For instance, when I naively start with a simple BeanFactory reference, I soon notice that I actually need a ConfigurableBeanFactory to simply shut it down (via destroySingletons()).
2) Automatic bean and bean factory post-processing only for application contexts?
Why is automatic bean and bean factory post-processing only supported for application contexts? To me this kind of functionality seems to benefit the core bean factory and is not so much an "application" functionality like the i18n provided by the application contexts. For a "BeanPostProcessor", you can programmatically register it with a ConfigurableBeanFactory, but this does not seem to be possible for a "BeanFactoryPostProcessor". So why is the "BeanFactoryPostProcessor" interface named that way? Wouldn't it be better to have an "ApplicationContextPostProcessor" instead of a "BeanFactoryPostProcessor", that way it would be clear that this is something that is only available for application contexts.
Any feedback on these topics would be appreciated.