Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes

[<jue...@we...>]

Peter,
=20
You've got a point here. The separation between a bean factory and an =
application context is that the former just deals with bean definitions, =
but does not treat defined beans (e.g. in an XML file) in special ways =
like the latter. An application context detects MessageSources, =
BeanPostProcessors, and BeanFactoryPostProcessors; a DispatcherServlet =
web application context even more of such special beans.
=20
I'd like to keep the bean factories as-is, mainly for programmatic use: =
You can register BeanPostProcessors, custom editors, etc via =
DefaultListableBeanFactory's configuration properties. An easy way to =
make post-processors available in EJB implementation classes would to be =
to simply load a ClassPathXmlApplicationContext instead of an =
XmlBeanFactory in the BeanFactoryLoader used. Of course, you can always =
implement such a custom loader yourself, but we can also consider making =
this the default loader.
=20
In any case, I completely agree that clarifying the default strategy in =
the docs is a must.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Peter den Haan
Gesendet: Mi 07.01.2004 22:22
An: spr...@li...
Betreff: [Springframework-developer] PostProcessor infrastructure in =
DefaultListableBeanFactory and EJB support classes


One thing that recently confused the heck out of me was that my AOP =
interceptors wouldn't work in an EJB context (1.0M4). Advice simply =
wasn't being applied to my beans even though precisely the same =
configuration worked fine in the web tier. Given that =
DefaultListableBeanFactory does contain the full BeanPostProcessor =
infrastructure, I didn't see how that could be.
=20
Upon closer examination, it turned out that the bean factory does not =
initialise its own BeanPostProcessors. Instead, =
AbstractApplicationContext does this by pulling all beans implementing =
BeanPostProcessor out of the factory and registering them in order =
before any of the other beans get instantiated. The XmlBeanFactoryLoader =
used by the EJB support classes, on the other hand, does no such thing. =
(Something similar can be said about BeanFactoryPostProcessors. Unless =
I'm missing something, this interface receives support only in an =
application context and has no bean hierarchy support at all.)
=20
Given that more and more of Spring's infrastructure relies on =
postprocessing, the BeanFactory support in AbstractEnterpriseBean seems =
crippled unless you roll your own XmlBeanFactoryLoader along the lines =
of attached class. We could do any of a number of things with this.

*	BeanPostProcessor registration could be made a responsibility of =
DefaultListableBeanFactory, although this might break existing software. =
I assume there's a good reason why this is an context rather than a =
factory responsibility.=20
*	A new loader along the lines of attached file could be added to the =
framework, and should probably used by default in =
AbstractEnterpriseBean. Wholesale cutting and pasting from =
AbstractApplicationContext can be avoided by migrating =
BeanFactoryPostProcessor and BeanPostProcessor registration to either a =
utility class or to utility methods in DefaultListableBeanFactory (these =
would not be part of the normal factory refresh, but would have to be =
invoked explicitly).=20
*	Instead of creating a new loader, BeanPostProcessor registration could =
simply be incorporated into XmlBeanFactoryLoader itself.=20
*	Everything could be left as is. In that case I feel the restrictions =
of bean support in a plain factory (as in EJBs) should be very clearly =
documented, otherwise this is going to confuse and discourage quite a =
few people.

Thanks for reading as far as this :) Let me know what you think. I would =
be more than happy to supply patches for the above against the current =
CVS head.
=20
 - Peter
=20
=20