|
From: <jue...@we...> - 2004-11-07 15:55:00
|
I would be very surprised if anyone is relying on the current order in =
detail. If a listener currently reacts to ContextClosedEvent, it can't =
do anything on existing bean instances, as they have already been =
destroyd. So if we publish the event before bean destruction now, =
existing logic in ContextClosedEvent should still work.
=20
(Thingking about it a second time, I doubt that anyone relies on =
ContextClosedEvent *at all*...)
=20
I have already changed that sequence, to be committed tonight.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: So 07.11.2004 16:21
An: spr...@li...
Betreff: Re: [Springframework-developer] ContextClosedEvent
+1 I think.
I don't like backwards incompatible changes, but the existing
implementation is simply wrong for any bean that is deployed into the
context, nobody in that case should be relying on the present sequence
as it doesn't make sense. I guess the other option is to not send out
the event to beans that have been destroyed, but that is a lot of work,
never mind mixing concerns that shouldn't be mixed, I think.
Now, do we have to worry about external objects (not deployed and
broadcast to automatically), that register for events manually, with the
appcontext?. Changing the sequence might mess them up, if they think
destroy has already been called on all beans. However, I don't see much
choice in the matter. I think most usage of the eventing mechanism will
be for application events (not context evetns), with the beans deployed
into the context, and we don't want to send those spurious events after
they have theoretically been destroyed.
j=FCrgen h=F6ller [werk3AT] wrote:
>Good point. I guess hardly anyone relies on ContextClosedEvent anyway, =
but for the sake of a clear state of listeners, we should publish that =
event *before* destroying beans. I'm inclinced to change that for 1.1.2 =
(which I now intend to release mid next week).
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Colin Sampaleanu
>Gesendet: Do 04.11.2004 02:08
>An: spr...@li...
>Betreff: [Springframework-developer] ContextClosedEvent
>
>
>
>I'm just documenting somehting on the ContextClosedEvent. It's called
>when all singletons have been destroyed (i.e. destroy method has been
>called)
>
> public void close() {
> if (logger.isInfoEnabled()) {
> logger.info("Closing application context [" +
>getDisplayName() + "]");
> }
>
> // Destroy all cached singletons in this context,
> // invoking DisposableBean.destroy and/or "destroy-method".
> ConfigurableListableBeanFactory beanFactory =3D =
getBeanFactory();
> if (beanFactory !=3D null) {
> beanFactory.destroySingletons();
> }
>
> // publish corresponding event
> publishEvent(new ContextClosedEvent(this));
> }
>
>I've personally never used the context closed event, but what I have to
>ask here is, does nobody else think this sequence is not usable and/or
>potentially dangerous. On the not usable part, an event listener must
>not have a destroy method, since the onApplicationEvent() would end up
>being called after the bean has been destroyed. As for potentially
>dangerous, that's if somebody forgets that they can't have a destroy
>method, and then spring does call the two methods in the wrong =
sequence.
>
>Colin
>=20
>
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|