Proposed Patch for #3733

["Craig R. McClanahan" <cr...@apache.org>]

Jon Stevens has proposed a patch to change the event order during the
process of a context reload (either because a modified class was detected
when you set reloadable to true, or manually via the Manager webapp).

Here's the current event order (in StandardContext.reload()):

(1) Pause requests temporarily

(2) Set the thread context class loader to the webapp's class loader

(3) Shut down and unload all defined servlets (calls destroy() if
    they have ever been initialized

(4) Remove all application-created attributes from the servlet context
    attributes (to avoid dangling references when we change class loaders)

(5) Shut down all registered filters and application event listeners

(6) Shut down the session manager (and serialize sessions to disk)

(7) Unset the thread context class loader

(8) Shut down, recreate, and restart the application's class loader

(9) Recreate the JNDI naming context for this application

(10) Set the thread context class loader to the webapp's class loader

(11) Restart the session manager (and deserialize sessions from disk)

(12) Restart registered application event listeners and filters

(13) Restart all currently defined servlets (but do not call init()
     on any of them yet)

(14) If defined servlets were marked load-on-startup, call init() on them
     in the same order that they were originally started.

(15) Unset the thread context class loader

(16) Unpause request processing

The proposed patch moves items (13) and (14) to be after item (10).  This
would have the effect of reloading (and re-init()-ing for load-on-startup
servlets) before the saved sessions were deserialized.  In principle, this
change should not cause any difficulties -- the only potential problem
would be if a servlet attempted to reference a session from within the
init() method, but this is not possible because you need a reference to a
request in order to acquire a reference to a session.

However, I would like to propose a slight alteration to thischange to
the reload() method, so that listeners and filters are also restarted
before the servlets are.  This is consistent with what happens when the
application originally starts up, and allows the init() method of a
servlet to assume that servlet context attributes created by a listener
(for example) will already be present.

Using this approach, the second half of the list (using the original item
numbers but the revised order) would look like this:

(10) Set the thread context class loader

(12) Restart registered application event listeners and filters

(13) Restart currently defined servlets

(14) Call init() on load-on-startup servlets

(11) Restart the session manager (and deserialize sessions from disk)

(15) Unset the thread context class loader

(16) Unpause request processing

Finally, the StandardContext.start() method should be modified so that
session reloading during initial application startup (i.e. right after you
start Tomcat) is also done after the listeners, filters, and servlets have
been initialized.  That way, session state reloading happens consistently
under all circumstances in which it is executed.

I cannot see that this would cause any difficulties with dependencies.
Can anyone else see a problem with it?

Craig McClanahan

Re: Proposed Patch for #3733

[Jon Stevens <jo...@latchkey.com>]

on 9/20/01 2:21 PM, "Craig R. McClanahan" <cr...@apache.org> wrote:

> I cannot see that this would cause any difficulties with dependencies.
> Can anyone else see a problem with it?
> 
> Craig McClanahan

+1

I'm ok with the filters being initialized first since I'm not using any. :-)

Thanks for the quick turnaround!

-jon