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

[Peter d. H. <pe...@de...>]

J=FCrgen H=F6ller wrote:

> I'd like to keep the bean factories as-is, mainly for programmatic use
[...]

I wouldn't advocate anything else -- changing the way bean factories work
would break a lot of stuff. The smallest change that could possibly work
would be to modify XmlBeanFactoryLoader to detect and register
postprocessors in the same way that AbstractApplicationContext does. This
would allow all the important Spring plumbing to work out of the box in t=
he
EJB tier, and I don't expect that it would break much (if anything).

Moving the postprocessor registration code to utility methods in BeanFact=
ory
is merely a suggested refactoring to prevent code duplication and would n=
ot
in any way change the way bean factories work.

> 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.

This is slightly more of a change, but would be an excellent option. IMHO
unless there is a strong reason to the contrary the default should be
something that supports postprocessors; either an application context, or=
 a
factory with initialised postprocessors as above.

 - Peter