Configuration reloading via Tomcat 7 parallel deployment ?

[Cantor, Scott]

On 11/22/13, 11:07 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

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

I think that's simply because Java abhors destructors.

Once you add a destroy component, I think you're left with a
synchronization problem if you're going to manage lifecycle separately.

I guess the question is, do we need the destroy half or not.

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

If we're going to support reloading while having a destroy API, then I
think that implies explicit locking or reference counting.

Did the V2 code have a destroy semantic on the components we reload?

-- Scott