[EMAIL PROTECTED] wrote:
 
> > My understanding is that ContextXmlReader actually produces 'fresh'
> > instances every time.
> 
> True. Do you think it would be better ( or simpler ) to just change
> ContextXmlReader to create a new set of per/context interceptors ?
> 
> My thinking was that the interceptors should be 'smart' about reloading,
> maybe they need to save/restore some state ( like a session interceptor ),
> or do some other actions.

Sorry about the late reply. Came down with a flu on the weekend...

Wouldn't really know about the simplicity of ContextXmlReader change. It
looks complicated to me, especially with the involvement of all the XML
machinery below it.

When I think about the whole thing a bit more, (apart from my headache
getting worse) it seems that your idea is much better and more
consistent with what Tomcat does now. Currently, there is no re-reading
of configuration files while Tomcat is running, so introducing that
would mean breaking that rule. And then we might end up with something
like this:

- Tomcat starts, ContextXmlReader does its job and user expects this to
be a one time occurrence
- there is a need for a context reload, so (changed) ContextXmlReader
runs again to pick up the config, but the configuration file was changed
and totally different local interceptors get loaded or even worse, the
old context doesn't exist any more
- user gets seriously frustrated and starts using swear words intermixed
with names from tomcat-dev list ;-)

Once I feel a bit better, I think I'll attempt your approach. Seems more
consistent and in line with what Tomcat does now. Plus it's probably
easier to do.

Thanks for pointing me in the right direction.

Bojan

Reply via email to