Remy Maucherat wrote:
Glenn Nielsen wrote:
Remy Maucherat wrote:
> [EMAIL PROTECTED] wrote:
>
>> glenn 2002/11/12 18:23:11
>>
>> Modified: catalina/src/share/org/apache/catalina/core
>> NamingContextListener.java
StandardContext.java
>> catalina/src/share/org/apache/naming
ContextBindings.java
>> Log:
>> Bug fix for BUG #13364
>>
>> A Web Application Context reload by the manager web application
>> was causing named JNDI resources to disappear.
>>
>> A webapp reload needs to dump the webapp classloader, then
>> recreate. The CL is bound to the naming context so the
>> reload was issing a NamingContext STOP_EVENT and then a
>> START_EVENT. This removed all the JNDI named resources
>> but the code which runs at webapp startup which creates
>> the JNDI named resources is not run on a reload.
>>
>> I fixed this by removing the START and STOP events and
>> adding BEFORE_STOP_EVENT and AFTER_START_EVENT
>> lifecycle events whose only purpose is to bind or unbind the
>> ClassLoader to the JNDI context.
>
>
>
>
> This fix seems incorrect to me. The naming context must be destroyed,
> as the references which are bound in it have been created by the old
> classloader.
>
Hmmm. You may have something here. But this would only affect resources
which are created who's classes exist within /WEB-INF/lib or
/WEB-INF/classes
and are loaded by the WebappClassLoader rather than a parent class
loader.
Yes, but this might happen. I thought about it more, and although it is
unlikely, it is a possibility. The main factory uses the context CL to
load the object factory, so it's legal to have it here.
After more investigation (and realizing I had missed the
"DefaultContext" keyword in the bug description. duh ! I suppose the
current mail lag caused me to waste a couple hours :-( ), I was able to
reproduce the bug. I have just committed a much simpler fix. It looks
safer, I think (the reload event is interpreted by the default context
as a stop/start, and that's it).
Sorry for the trouble.
Remy
Thats ok. I am glad you reviewed the patch.
I caught that the Context had to be unbound from the old CL and rebound to
the new CL but didn't consider that some of the resources may have been
created using classess loaded by the old CL.
I tested your patch and it works fine.
Thanks,
Glenn
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
