Configuration reloading via Tomcat 7 parallel deployment ?

[Rod Widdowson]

> It would be very dismaying if Spring can't do what I managed to do in one
> C++ base class.

This echo's my frustration with this.  We all know that the whole think can
be done in less than an afternoon, the code is not tricky and many of us
have done this sort of thing enough times to be able to code it in our
sleep.   But we want to believe that Spring will do it for us.

Marvin earlier said:

> DispatcherServlet case and it appears it's designed to continue
> processing requests while the underlying application context is
> refreshed 
> . I simply don't see anything like an IO wait or monitor wait
> that would block requests while the context internal state is updated.
> I think some testing is in order to say for certain, but looks
> promising.

In contrast to the reload code I am far from an expert with this stuff, so
take what follows with a pinch of salt:  I coded up a little jsp servlet (to
run inside DispatcherServlet) which took 16 seconds to look at a bean
(looking every 3 seconds).  Meanwhile the Web App context was being
refreshed via the DispatcherServlet every 2 seconds.  From what I observed,
whilst the bean wasn't moving under our feet there was no interlock against
destroy being called while the bean was being used.  

Further if I broke the configuration then later attempts to access the
servlet failed with a 500 error.

I am pretty sure that my experiment is less than rigorous (and may well be
far from correct) and I expect that there may even be another way to do this
by being smarter.   However having spent a great deal of time in nature
study I am becoming aware of the law of diminishing returns.

What we want to do is *not* complicated, is not necessarily un-spring like
(I have another mail to compose about DestructableComponent vs
DisposableBean to clarify that), is it time to just do what we know and move
on?

Rod