Spring framework: my 2 cents

[klr8]

Hello,

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.



Erwin

[robh]

Erwin,

I totally take your comments onboard and I think that, to some degree, you have a point. However, since Spring is a framework is has to be ultimately flexible. It is hard to encounter a situation of YAGNI with a framework because although you and I might not need a feature, what is to say somebody else won't. For Spring to see widespread acceptance - which is what we want - it has to be flexible enough to handle the majority of cases, even a few more esoteric ones!

Your point about BeanFactory is valid to a point, but remember that the Spring documentation is pushing at least XmlBeanFactory and more commonly an XML ApplicationContext like ClassPathXmlApplicationContext. These are the classes that we see most people using in their applications and these implement all the relevant interfaces. The reason for all the different interfaces is again an issue of flexibility as a core focus of a framework.

As for BeanPostProcessor, well that got me first time around so I am inclined to agree with you a little However, I do like the fact I can back out of all that 'framework-oriented' functionality and get just a really simple container to hold my beans.

Thanks for posting your opinions, its great to get some constructive feedback and I'm glad to see you are using Spring. Keep on posting, feedback like this will really us to keep on improving Spring.

Rob

[Juergen Hoeller]

Erwin,

Thanks for your feedback, and for your kind words on Spring and our book! I understand why you wonder about those design decisions; let me try to explain them a bit further.

ad 1)
Indeed, the internals of the BeanFactory implementations are not trivial. However, you usually don't have to worry about them too much anyway: Just stick to the client views in the beans.factory package.

The BeanFactory and ListableBeanFactory interfaces are the client view of a bean factory, while Configurable(Listable)BeanFactory is just needed to manage the lifecycle of a bean factory itself. Typical clients should not see the methods to configure or shut down a bean factory but just the ones to access beans - therefore the separation.

ad 2)
A BeanFactory is just a plain IoC container. In particular, it does not auto-detect special beans but rather treats all beans the same - in contrast to an ApplicationContext.

Consequently, an ApplicationContext auto-detects BeanPostProcessors and BeanFactoryPostProcessors that are define as beans in it, while a plain BeanFactory needs programmatic calls for those. I do believe that this is a valuable separation. A typical ApplicationContext also detects other special beans, like a MessageSource, ThemeSource, etc.

A BeanPostProcessor needs to be applied to each bean created by a factory, therefore a BeanFactory absolutely has to know about it. A BeanFactoryPostProcessor on the other hand works on a BeanFactory itself: Simply invoke it with the given BeanFactory as argument. The BeanFactory itself does not have to know about this.

I hope this clarifies a few things,

Juergen

[klr8]

Okay,

I agree that ease of use by the average user, that does not worry about Spring internals, is an important design goal. Very simple client interfaces is a valid way to attain this.

Regarding issue 2. If I understand this correctly, the BeanFactoryPostProcessor carries the "BeanFactory" prefix since it is a general strategy to post-process any bean factory. In itself it does not impose an application mechanism (e.g. programmattically or automatically in an application context). Seems reasonable.


Thanks for the feedback!

Erwin