springframework-developer

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

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

I've had a couple of discussions now with people where I've tried to=20
explain why setApplicationContext comes after afterPropertiesSet (and=20
after any custom initializing method you define), and frankly, I think=20
it just doesn't make sense except for the fact that it's that way right n=
ow.

Most beans should of course not be using the application context, but if=20
they need it, people are not going to understand the rationale as to why=20
that property is set after the initializing method is called, and that=20
they must instead treat setApplicationContext itself as an initializer=20
method.

I don't know if anybody thinks it's worth changing the order, but if=20
not, this thing is going to hit new users on the head on a regular=20
basis... At a minimum, if no code is changed, we need to update the=20
JavaDoc for ApplicationContextAware to explain the order. I can do that..=
.

Regards,
Colin

j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:

>Actually, this is intended behavior, although it may be debatable whethe=
r it is appropriate. setApplicationContext is not really meant to be comb=
ined 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 sh=
ould *not* design your beans to depend on that initialization order.
>
>As a solution, you could put your initialization code in your setApplica=
tionContext implementation, or in an initApplicationContext() method that=
 gets triggered by setApplicationContext. Have a look at the ApplicationO=
bjectSupport convenience base class, it provides such a method out of the=
 box. Of course, extending ApplicationObjectSupport is not an option if y=
ou already have a different natural base class.
>
>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 be=
ing called now on all my ApplicationContextAware beans, thanks.  The only=
 issue I have remaining is it seems the bean init-method method ("initial=
ize()" in my case) is called by the container before setApplicationContex=
t.  My initialize() method does stuff that requires the context - for exa=
mple, it looks up messages for initializing view components.  So I would =
really need setApplicationContext() called before initialize() to prevent=
 NullPointerExceptions.
>
>Thanks,
>Keith
>
>2003-10-30 10:16:58,099 DEBUG [com.csi.cogids.console.QueryNavigator] - =
<initialize called>
>2003-10-30 10:16:58,193 DEBUG [com.csi.cogids.console.qQueryNavigator] -=
 <setApplicationContext called>
>
>Keith Donald
>Senior Software Engineer
>kd...@cs...
>321-676-2923 x403
>
>
>
>
>-----Original Message-----
>From: spr...@li... [mailto:springfra=
mew...@li...] On Behalf Of j=C3=BCrgen h=C3=B6=
ller [werk3AT]
>Sent: Thursday, October 23, 2003 2:14 AM
>To: spr...@li...
>Subject: Re: [Springframework-user] setApplicationContext not being call=
ed
>
>
>Keith,
>=20
>This was caused by the fact that ApplicationContextAware was being proce=
ssed after the underlying bean factory finished its work, on demand in ge=
tBean 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 appli=
ed 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 a=
ll cases. If there should be any remaining issues, please report them aga=
inst 1.0 M2. If you're eager, you can also try a CVS snapshot today.
>=20
>Juergen
>=20
>=20
>
>	-----Urspr=C3=BCngliche Nachricht-----=20
>	Von: Keith Donald [mailto:kd...@cs...]=20
>	Gesendet: Di 21.10.2003 19:50=20
>	An: spr...@li...=20
>	Cc:=20
>	Betreff: [Springframework-user] setApplicationContext not being called
>=09
>=09
>
>	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.
>=09
>	To give you an example of what I mean:
>=09
>	        // 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>
>=09
>	        // 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>
>=09
>	A sessionVisualizerPage prototype gets instantiated when the page is lo=
aded
>	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.
>=09
>	Thanks,
>	Keith
>=09
>	Keith Donald
>	Senior Software Engineer
>	kd...@cs...
>	321-676-2923 x403
>=09
>

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

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

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. Perhaps
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 n=
ow.

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:

>Actually, this is intended behavior, although it may be debatable whethe=
r
it is appropriate. setApplicationContext is not really meant to be combin=
ed
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.
>
>As a solution, you could put your initialization code in your
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 metho=
d
out of the box. Of course, extending ApplicationObjectSupport is not an
option if you already have a different natural base class.
>
>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 be=
ing
called now on all my ApplicationContextAware beans, thanks.  The only iss=
ue
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, i=
t
looks up messages for initializing view components.  So I would really ne=
ed
setApplicationContext() called before initialize() to prevent
NullPointerExceptions.
>
>Thanks,
>Keith
>
>2003-10-30 10:16:58,099 DEBUG [com.csi.cogids.console.QueryNavigator] -
<initialize called>
>2003-10-30 10:16:58,193 DEBUG [com.csi.cogids.console.qQueryNavigator] -
<setApplicationContext called>
>
>Keith Donald
>Senior Software Engineer
>kd...@cs...
>321-676-2923 x403
>
>
>
>
>-----Original Message-----
>From: spr...@li...
[mailto:spr...@li...] On Behalf Of
j=C3=BCrgen h=C3=B6ller [werk3AT]
>Sent: Thursday, October 23, 2003 2:14 AM
>To: spr...@li...
>Subject: Re: [Springframework-user] setApplicationContext not being call=
ed
>
>
>Keith,
>
>This was caused by the fact that ApplicationContextAware was being
processed after the underlying bean factory finished its work, on demand =
in
getBean calls to the application context. I've completely reworked this f=
or
1.0 M2; now, the bean factory has a BeanPostProcessor hook that is also
internally used for processing ApplicationContextAware beans, to be appli=
ed
when the underlying bean factory creates any kind of bean.
>
>So as of 1.0 M2, to be released tomorrow, this should work properly in a=
ll
cases. If there should be any remaining issues, please report them agains=
t
1.0 M2. If you're eager, you can also try a CVS snapshot today.
>
>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
loaded
> 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
>
>




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

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

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

I was hoping for some more discussion on this, but it looks like nobody 
bit...

In the meantime, I have clarified the existing ordering of the lifecycle 
methods in the JavaDocs for InitializingBean, BeanFactoryAware, and 
ApplcationContextAware.

I still think there somewhat of a (big) hole with regards to the current 
initializing method handling. Currently, BeanPostProcessors are all 
applied _after_ ApplicationContextAware (although this order is not 
documented). This works for any BeanPostProcessors which expect to be 
given fully initialized beans, as they will be given a bean initialized 
fully (and knowing it) due to use of afterPropertiesSet 
(InitializingBean), setBeanFactory (BeanFactoryAware), or 
setApplicationContext (ApplicationContextAware). However, if somebody 
needs to apply a BeanPostProcessor to set some properties of a bean as 
part of the initialization, there is _no_ reliable mechanism to call an 
init method on the bean afterwards; neither via an entry in the XML def, 
nor via a marker interface.

What makes the most sense to _me_ is to have the following sequence apply:
-  BeanFactoryAware, ApplicationContextAware, a set of 'initializing' 
BeanPostProcessors, InitializingBean, and finally a another set of 
'post-initializing' BeanPostProcessors.

This obviously has implications in terms of backwards compatibility 
since InitializingBean applies in a different sequence. A solution which 
would be completely backwards compatible (but I think less obvious), 
would be to do
- InitializingBean, BeanFactoryAware, 'initializing' BeanPostProcessors, 
ApplicationContextAware, 'post-initializing' BeanPostProcessors. People 
could in this case use any of the three marker interfaces to initialize, 
as suitable...

Any comments?

Regards,
Colin

Colin Sampaleanu wrote:

> I think any distinction between 'basic JavaBean stuff' and 
> 'application context stuff' is often going to be artificial. If you 
> think about some class that actually needs the context, it is probably 
> going to use it in a similar fashion to any other property inside it.
>
> But the initialize method (or the specific instance 
> afterPropertiesSet) is also a lifecycle method, and it is in the wrong 
> order as far as _any_ BeanPostProcessors are concerned, including 
> ApplicationContextAware. Right now there is no mechanism to specify 
> that an init method should be called after everything has been done to 
> it by the context, including post processors. You can't even rely on 
> setApplicationContext() as your 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, with working beans, and if you need something special 
> from the application context (like the post-processors, or indirectly, 
> via the fact that one of its dependencies needs the application 
> context) just switch to using the same setup in an application 
> context. You can't really do that if you can no longer rely on the 
> original init methods from when you were in the bean factory.
>
> So for sure I think there is a need for the ability to call an init 
> method once post-processing is done, and I can't see the justification 
> 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. 
>> Perhaps
>> the "set" prefix was unwise.
>>
>> Regards,
>> Rod
>>
>> ----- Original Message ----- 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ürgen höller [werk3AT] wrote:
>>
>>  
>>
>>> Actually, this is intended behavior, although it may be debatable 
>>> whether
>>>   
>>
>> it is appropriate. setApplicationContext is not really meant to be 
>> combined
>> 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.
>>  
>>
>>> As a solution, you could put your initialization code in your
>>>   
>>
>> 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 
>> method
>> out of the box. Of course, extending ApplicationObjectSupport is not an
>> option if you already have a different natural base class.
>>  
>>
>>> 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 being
>>>   
>>
>> called now on all my ApplicationContextAware beans, thanks.  The only 
>> issue
>> 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 need
>> setApplicationContext() called before initialize() to prevent
>> NullPointerExceptions.
>>  
>>
>>> Thanks,
>>> Keith
>>>
>>> 2003-10-30 10:16:58,099 DEBUG [com.csi.cogids.console.QueryNavigator] -
>>>   
>>
>> <initialize called>
>>  
>>
>>> 2003-10-30 10:16:58,193 DEBUG 
>>> [com.csi.cogids.console.qQueryNavigator] -
>>>   
>>
>> <setApplicationContext called>
>>  
>>
>>> Keith Donald
>>> Senior Software Engineer
>>> kd...@cs...
>>> 321-676-2923 x403
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>>   
>>
>> [mailto:spr...@li...] On Behalf Of
>> jürgen höller [werk3AT]
>>  
>>
>>> Sent: Thursday, October 23, 2003 2:14 AM
>>> To: spr...@li...
>>> Subject: Re: [Springframework-user] setApplicationContext not being 
>>> called
>>>
>>>
>>> Keith,
>>>
>>> This was caused by the fact that ApplicationContextAware was being
>>>   
>>
>> 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 
>> applied
>> when the underlying bean factory creates any kind of bean.
>>  
>>
>>> So as of 1.0 M2, to be released tomorrow, this should work properly 
>>> in all
>>>   
>>
>> cases. If there should be any remaining issues, please report them 
>> against
>> 1.0 M2. If you're eager, you can also try a CVS snapshot today.
>>  
>>
>>> Juergen
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht----- 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 
>>> instantiated
>>> 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="sessionVisualizerPage"
>>>                class="com.csi.cogids.console.SessionVisualizerPage"
>>>            singleton="false">
>>>          <property name="queryNavigator"><ref
>>> bean="queryNavigator"/></property>
>>>     </bean>
>>>
>>>        // child prototype
>>>    <bean       id="queryNavigator"
>>>             class="com.csi.cogids.console.query.QueryNavigator"
>>>         singleton="false"
>>>       init-method="initialize">
>>>      <property name="newQueryAction"><ref
>>> bean="newQueryAction"/></property>
>>>      <property name="newGroupAction"><ref
>>> bean="newGroupAction"/></property>
>>>    </bean>
>>>
>>> A sessionVisualizerPage prototype gets instantiated when the page is
>>>   
>>
>> loaded
>>  
>>
>>> 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
>>>    
>>