Re: [Springframework-developer] BeanFactoryPostProcessor

[Rod J. <rod...@in...>]

+1
----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: "jürgen höller [werk3AT]" <jue...@we...>; "Rod Johnson"
<rod...@in...>
Cc: <spr...@li...>
Sent: Sunday, October 12, 2003 12:36 PM
Subject: Re: [Springframework-developer] BeanFactoryPostProcessor


> On second thought, I'm actually for making the BeanFactoryPostPrcessor
interface non-ApplicationContextAware and moving it to the
beans.factory.support, even if doesn't have to be known by any BeanFactory
implementation.
>
> Applications might want to use it to implement post-processing code that
they manually invoke on a BeanFactory after programmatically loading it,
just like an ApplicationContext does internally.
>
> Furthermore, it just seems more consistent to have
BeanFactoryPostProcessor in the same package as BeanPostProcessor, even if
there are conceptual differences between the two.
>
> I guess I'll apply that change promptly, tomorrow at the latest. Any
objections?
>
> Juergen
>
>
>
> -----Ursprüngliche Nachricht----- 
> Von: jürgen höller [werk3AT]
> Gesendet: Sa 11.10.2003 01:06
> An: Rod Johnson
> Cc: spr...@li...
> Betreff: [Springframework-developer] Re: BeanFactoryPostProcessor
>
>
>
> There isn't a strong reason for BeanFactoryPostProcessor being
ApplicationContextAware: It's just that almost all implementations will be,
as they need to load some resources that they take their additional
configuration like overridden property values from. Resource loading is a
major reason for an application context (ApplicationContext's
getResourceAsStream and getResourceBase methods), just like a message
source.
>
> The BeanFactoryPostProcessor interface could reside in the
beans.factory.support package, but IMO it conceptually belongs to the
context area. A bean factory itself does not know about being
post-processed: That's a concept added by an application context, applied to
its underlying bean factory. Bean factories can be programmatically
manipulated after loading their original definitions, but only application
contexts allow to do this via special beans that get auto-detected
(BeanFactoryPostProcessor in this case, but also BeanPostProcessor).
>
> As I've already mentioned in a previous mail, I've applied the principle
that bean factories should not need to detect special beans defined within
them that influence the factory behavior itself. Bean factories and their
behavior get configured programmatically; the FactoryBean interface is an
exception, as it's not really manipulating the factory implementation.
Application contexts on the other hand recognize numerous special beans:
MessageSource, ContextOptions, BeanFactoryPostProcessors,
BeanPostProcessors.
>
> Note that the bean factory implementation does have to know about
BeanPostProcessor in a programmatic fashion, as this influences its bean
creation behavior. It does not have to know about BeanFactoryPostProcessor
though: That can easily get managed from the outside, i.e. by an application
context for its underlying bean factory, as it's basically just about
various method calls to the bean factory instance after loading the original
bean definitions.
>
> Of course, we could still decide to make the BeanFactoryPostProcessor
interface non-ApplicationContextAware and move it to beans.factory.support:
It would just not get used by any bean factory implementation or helper
class, but rather only by application context implementations -- therefore
it doesn't *have* to reside in the beans package. As elaborated above,
BeanPostProcessor is significantly different in that respect.
>
> Juergen
>
>
>
>         -----Ursprüngliche Nachricht-----
>         Von: Rod Johnson [mailto:rod...@in...]
>         Gesendet: Fr 10.10.2003 22:21
>         An: jürgen höller [werk3AT]
>         Cc: spr...@li...
>         Betreff: BeanFactoryPostProcessor
>
>
>
>         Juergen,
>
>         Why is this in the context package and why is it ContextAware?
Shouldn't it
>         deal only in Beanfactory concepts?
>
>         Forgive my ignorance if there's a good reason--this is based on a
>         superficial look at stuff coming in from CVS, rather than deep
thought.
>
>         Regards,
>         Rod
>
>
>
>
> NHY޵隊X'uw+m$>
xZ+޶,/zMҢx-'ze{hB5/כz^ǫ')brH^mqz캚h׫iJjgzx%Rڙ(G^hlqzm?X(~zwXb?j
gz
>
>