Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()

[Colin S. <col...@ex...>]

I think any distinction between 'basic JavaBean stuff' and 'application=20
context stuff' is often going to be artificial. If you think about some=20
class that actually needs the context, it is probably going to use it in=20
a similar fashion to any other property inside it.

But the initialize method (or the specific instance afterPropertiesSet)=20
is also a lifecycle method, and it is in the wrong order as far as _any_=20
BeanPostProcessors are concerned, including ApplicationContextAware.=20
Right now there is no mechanism to specify that an init method should be=20
called after everything has been done to it by the context, including=20
post processors. You can't even rely on setApplicationContext() as your=20
init method because in fact some post-processors may act after it.

If you think about it, you should be able to take a working beanfactory,=20
with working beans, and if you need something special from the=20
application context (like the post-processors, or indirectly, via the=20
fact that one of its dependencies needs the application context) just=20
switch to using the same setup in an application context. You can't=20
really do that if you can no longer rely on the original init methods=20
from when you were in the bean factory.

So for sure I think there is a need for the ability to call an init=20
method once post-processing is done, and I can't see the justification=20
for making this different than the existing beanfactory init mechanism...

Regards,
Colin

Rod Johnson wrote:

>Colin,
>
>I like the present order: not surprisingly, perhaps, as I chose it. The
>rationale is: get the basic JavaBean stuff in order first, then do any
>application context stuff.
>
>Certainly the docs should be consistent.
>
>Now at least I understand the confusion: setApplicationContext() is not
>treated as a normal JavaBean property, but as a lifecycle method. Perhap=
s
>the "set" prefix was unwise.
>
>Regards,
>Rod
>
>----- Original Message -----=20
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Monday, January 05, 2004 8:35 PM
>Subject: [Springframework-developer] Rationale for setApplicationContext=
()
>coming after afterPropertiesSet()
>
>
>I've had a couple of discussions now with people where I've tried to
>explain why setApplicationContext comes after afterPropertiesSet (and
>after any custom initializing method you define), and frankly, I think
>it just doesn't make sense except for the fact that it's that way right =
now.
>
>Most beans should of course not be using the application context, but if
>they need it, people are not going to understand the rationale as to why
>that property is set after the initializing method is called, and that
>they must instead treat setApplicationContext itself as an initializer
>method.
>
>I don't know if anybody thinks it's worth changing the order, but if
>not, this thing is going to hit new users on the head on a regular
>basis... At a minimum, if no code is changed, we need to update the
>JavaDoc for ApplicationContextAware to explain the order. I can do that.=
..
>
>Regards,
>Colin
>
>j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:
>
> =20
>
>>Actually, this is intended behavior, although it may be debatable wheth=
er
>>   =20
>>
>it is appropriate. setApplicationContext is not really meant to be combi=
ned
>with an init-method. The latter is for non-Spring-aware beans, while the
>former is the strongest dependency a bean can have on Spring. You should
>*not* design your beans to depend on that initialization order.
> =20
>
>>As a solution, you could put your initialization code in your
>>   =20
>>
>setApplicationContext implementation, or in an initApplicationContext()
>method that gets triggered by setApplicationContext. Have a look at the
>ApplicationObjectSupport convenience base class, it provides such a meth=
od
>out of the box. Of course, extending ApplicationObjectSupport is not an
>option if you already have a different natural base class.
> =20
>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: Keith Donald [mailto:kd...@cs...]
>>Sent: Thursday, October 30, 2003 4:22 PM
>>To: spr...@li...
>>Subject: RE: [Springframework-user] setApplicationContext not being
>>called
>>
>>
>>Juergen,
>>
>>Wanted to update you on this issue post M2.  setApplicationContext is b=
eing
>>   =20
>>
>called now on all my ApplicationContextAware beans, thanks.  The only is=
sue
>I have remaining is it seems the bean init-method method ("initialize()"=
 in
>my case) is called by the container before setApplicationContext.  My
>initialize() method does stuff that requires the context - for example, =
it
>looks up messages for initializing view components.  So I would really n=
eed
>setApplicationContext() called before initialize() to prevent
>NullPointerExceptions.
> =20
>
>>Thanks,
>>Keith
>>
>>2003-10-30 10:16:58,099 DEBUG [com.csi.cogids.console.QueryNavigator] -
>>   =20
>>
><initialize called>
> =20
>
>>2003-10-30 10:16:58,193 DEBUG [com.csi.cogids.console.qQueryNavigator] =
-
>>   =20
>>
><setApplicationContext called>
> =20
>
>>Keith Donald
>>Senior Software Engineer
>>kd...@cs...
>>321-676-2923 x403
>>
>>
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>   =20
>>
>[mailto:spr...@li...] On Behalf Of
>j=C3=BCrgen h=C3=B6ller [werk3AT]
> =20
>
>>Sent: Thursday, October 23, 2003 2:14 AM
>>To: spr...@li...
>>Subject: Re: [Springframework-user] setApplicationContext not being cal=
led
>>
>>
>>Keith,
>>
>>This was caused by the fact that ApplicationContextAware was being
>>   =20
>>
>processed after the underlying bean factory finished its work, on demand=
 in
>getBean calls to the application context. I've completely reworked this =
for
>1.0 M2; now, the bean factory has a BeanPostProcessor hook that is also
>internally used for processing ApplicationContextAware beans, to be appl=
ied
>when the underlying bean factory creates any kind of bean.
> =20
>
>>So as of 1.0 M2, to be released tomorrow, this should work properly in =
all
>>   =20
>>
>cases. If there should be any remaining issues, please report them again=
st
>1.0 M2. If you're eager, you can also try a CVS snapshot today.
> =20
>
>>Juergen
>>
>>
>>
>>-----Urspr=C3=BCngliche Nachricht-----=20
>>Von: Keith Donald [mailto:kd...@cs...]
>>Gesendet: Di 21.10.2003 19:50
>>An: spr...@li...
>>Cc:
>>Betreff: [Springframework-user] setApplicationContext not being called
>>
>>
>>
>>Forgive me if this issue has already been addressd.  It appears
>>setApplicationContext(ApplicationContext) is not being called on my
>>ApplicationContextAware prototype beans that are not directly instantia=
ted
>>by a call to beanFactory.getBean(beanName), but rather are wired "child=
"
>>beans instantiated as a result of a <bean ref> references from a parent
>>prototype.
>>
>>To give you an example of what I mean:
>>
>>        // parent prototype
>>        <bean      id=3D"sessionVisualizerPage"
>>                class=3D"com.csi.cogids.console.SessionVisualizerPage"
>>            singleton=3D"false">
>>          <property name=3D"queryNavigator"><ref
>>bean=3D"queryNavigator"/></property>
>>     </bean>
>>
>>        // child prototype
>>    <bean       id=3D"queryNavigator"
>>             class=3D"com.csi.cogids.console.query.QueryNavigator"
>>         singleton=3D"false"
>>       init-method=3D"initialize">
>>      <property name=3D"newQueryAction"><ref
>>bean=3D"newQueryAction"/></property>
>>      <property name=3D"newGroupAction"><ref
>>bean=3D"newGroupAction"/></property>
>>    </bean>
>>
>>A sessionVisualizerPage prototype gets instantiated when the page is
>>   =20
>>
>loaded
> =20
>
>>in my application.  The queryNavigator prototype also gets instantiated
>>because of the <bean ref>.  setApplicationContext() IS called on
>>sessionVisualizerPage, but not on QueryNavigator, even though both are
>>ApplicationContextAware for message lookups.
>>
>>Thanks,
>>Keith
>>
>>Keith Donald
>>Senior Software Engineer
>>kd...@cs...
>>321-676-2923 x403
>>   =20
>>