Hi Bojan,
A simpler solution is to fix ReloadInterceptor - and save the current list
of interceptors before removing the context, then add all per/context
interceptors after the context is added back ( those having getContext()
!= null ).
This would deal with other configuration mechanisms as well -
ContextXmlReader is not the only way to add contexts, applications
embeding tomcat may use API calls as well.
Dealing with changes in app.xml is a bit more difficult - and I think the
right long-term solution is to consolidate all config modules and create a
smart 'deploy tool' module that can take care of all the issues.
Costin
On Thu, 20 Sep 2001, Bojan Smojver wrote:
> Bojan Smojver wrote:
>
> > Is this something that happens by design or am I looking at a possible
> > bug?
>
> By following what happens when TC starts and when it reloads the
> context, it seems that there should be contextInit() method in
> ContextXmlReader.
>
> This interceptor is responsible for calling the
> ServerXmlReader.loadConfigFile() which in turn (after a series of XML
> related calls on the stack) calls Context.addInterceptor(), which is
> responsible for adding all local (to the context) interceptors.
>
> If ContextXmlReader had contextInit() method, this would happen every
> time the context is reloaded and all local interceptors (including my
> JDBCRealm :-) would be picked up. Sweeeet!
>
> Now that's all cool, but I wouldn't have a clue how to write that
> method. If you guys can point me in the right direction...
>
> Thanks,
> Bojan
>
