RE: [Springframework-developer] Rationale for setApplicationConte xt() coming after afterPropertiesSet()

[Kopylenko, D. <dko...@ac...>]

I think that setApplicationContext() is not a bad name for a lifecycle
method - similar to EJB's setSessionContext().

Just my 2c.

Dmitriy.

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]=20
Sent: Tuesday, January 06, 2004 4:31 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Rationale for
setApplicationContext() coming after afterPropertiesSet()


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 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=FCrgen h=F6ller [werk3AT] wrote:

>Actually, this is intended behavior, although it may be debatable=20
>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=20
>called
>
>
>Juergen,
>
>Wanted to update you on this issue post M2.  setApplicationContext is=20
>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=FCrgen h=F6ller [werk3AT]
>Sent: Thursday, October 23, 2003 2:14 AM
>To: spr...@li...
>Subject: Re: [Springframework-user] setApplicationContext not being=20
>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=FCngliche 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=20
> ApplicationContextAware prototype beans that are not directly=20
> instantiated by a call to beanFactory.getBean(beanName), but rather=20
> are wired "child" beans instantiated as a result of a <bean ref>=20
> 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=20
> 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=20
> bean=3D"newQueryAction"/></property>
>       <property name=3D"newGroupAction"><ref=20
> bean=3D"newGroupAction"/></property>
>     </bean>
>
> A sessionVisualizerPage prototype gets instantiated when the page is
loaded
> in my application.  The queryNavigator prototype also gets=20
> instantiated because of the <bean ref>.  setApplicationContext() IS=20
> called on sessionVisualizerPage, but not on QueryNavigator, even=20
> 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




-------------------------------------------------------
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=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer