You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by gl...@apache.org on 2002/11/13 03:23:11 UTC
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming ContextBindings.java
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.
Defined JNDI resources are now preserved on a web app reload.
Revision Changes Path
1.20 +43 -18 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/NamingContextListener.java
Index: NamingContextListener.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/NamingContextListener.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- NamingContextListener.java 25 Jun 2002 22:29:23 -0000 1.19
+++ NamingContextListener.java 13 Nov 2002 02:23:10 -0000 1.20
@@ -293,26 +293,13 @@
log(sm.getString("naming.namingContextCreationFailed", e));
}
- // Binding the naming context to the class loader
- if (container instanceof Context) {
- // Setting the context in read only mode
- ContextAccessController.setReadOnly(getName());
- try {
- ContextBindings.bindClassLoader
- (container, container,
- ((Container) container).getLoader().getClassLoader());
- } catch (NamingException e) {
- log(sm.getString("naming.bindFailed", e));
- }
- }
-
if (container instanceof Server) {
namingResources.addPropertyChangeListener(this);
org.apache.naming.factory.ResourceLinkFactory.setGlobalContext
(namingContext);
try {
ContextBindings.bindClassLoader
- (container, container,
+ (container, container,
this.getClass().getClassLoader());
} catch (NamingException e) {
log(sm.getString("naming.bindFailed", e));
@@ -321,9 +308,47 @@
((StandardServer) container).setGlobalNamingContext
(namingContext);
}
+ } else if (container instanceof Context) {
+ // Setting the context in read only mode
+ ContextAccessController.setReadOnly(getName());
+ try {
+ ContextBindings.bindClassLoader
+ (container, container,
+ ((Container) container).getLoader().getClassLoader());
+ } catch (NamingException e) {
+ log(sm.getString("naming.bindFailed", e));
+ }
}
initialized = true;
+
+ } else if (event.getType() == Lifecycle.AFTER_START_EVENT ) {
+ // Used at end of a Web Application Context reload
+ if (container instanceof Context) {
+ // Setting the context in read only mode
+ ContextAccessController.setReadOnly(getName());
+ try {
+ ContextBindings.bindClassLoader
+ (container, container,
+ ((Container) container).getLoader().getClassLoader());
+ } catch (NamingException e) {
+ log(sm.getString("naming.bindFailed", e));
+ }
+ }
+
+ } else if (event.getType() == Lifecycle.BEFORE_STOP_EVENT) {
+ // Used when starting a Web Application Context reload
+ if (!initialized)
+ return;
+
+ // Setting the context in read/write mode
+ ContextAccessController.setWritable(getName(), container);
+
+ if (container instanceof Context) {
+ ContextBindings.unbindClassLoader
+ (container, container,
+ ((Container) container).getLoader().getClassLoader());
+ }
} else if (event.getType() == Lifecycle.STOP_EVENT) {
1.114 +6 -6 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.113
retrieving revision 1.114
diff -u -r1.113 -r1.114
--- StandardContext.java 26 Sep 2002 10:25:03 -0000 1.113
+++ StandardContext.java 13 Nov 2002 02:23:10 -0000 1.114
@@ -2486,7 +2486,7 @@
if (isUseNaming()) {
// Start
namingContextListener.lifecycleEvent
- (new LifecycleEvent(this, Lifecycle.STOP_EVENT));
+ (new LifecycleEvent(this, Lifecycle.BEFORE_STOP_EVENT));
}
// Binding thread
@@ -2522,7 +2522,7 @@
if (isUseNaming()) {
// Start
namingContextListener.lifecycleEvent
- (new LifecycleEvent(this, Lifecycle.START_EVENT));
+ (new LifecycleEvent(this, Lifecycle.AFTER_START_EVENT));
}
// Binding thread
1.8 +10 -6 jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/ContextBindings.java
Index: ContextBindings.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/ContextBindings.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ContextBindings.java 31 May 2002 02:55:21 -0000 1.7
+++ ContextBindings.java 13 Nov 2002 02:23:11 -0000 1.8
@@ -309,8 +309,12 @@
if (context == null)
throw new NamingException
(sm.getString("contextBindings.unknownContext", name));
- clBindings.put(classLoader, context);
- clNameBindings.put(classLoader, name);
+ Object n = clNameBindings.get(classLoader);
+ // Only bind CL if it isn't already bound to the context
+ if (n == null) {
+ clBindings.put(classLoader, context);
+ clNameBindings.put(classLoader, name);
+ }
}
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming
ContextBindings.java
Posted by Glenn Nielsen <gl...@mail.more.net>.
Remy Maucherat wrote:
> Remy Maucherat wrote:
>
>> glenn@apache.org 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.
>>
>> The NamingResources object is supposed to contain all the necessary data
>> to recrate the JNDI context. The question, and what I was planning to
>> investigate, is why it doesn't work. I think it did in the past.
>>
>> I'll revert this patch when I find a better fix for the bug.
>
>
>
> I investigated the problem as much as I could, and I cannot reproduce
> the original bug.
> The patch introduces wrong behavior as explained, so I am -1 for it, and
> will revert it.
>
> The original report was that the JNDI resources were disappearing after
> a reload of a context using the manager.
> Here is what I did to try to reproduce it:
> - full recompile and start of Tomcat 4.1, after adding a user for the
> manager webapp
> - use of the JNDI servlet to display the naming environment of the
> "examples" context (http://127.0.0.1:8080/examples/servlet/JndiServlet)
> - use of the HTML interface to the manager to reload the "examples"
> context (http://127.0.0.1:8080/manager/html/reload?path=/examples)
> - reload was successful
> - use JNDI servlet in a different browser (Moz, the first one was in
> IE); result is the same as the first attempt
>
> So I would like detailed information on:
> - what is actually failing
> - how to reproduce it
>
I can reproduce the bug every time when the resource is defined in the
DefaultContext.
Regards,
Glenn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming
ContextBindings.java
Posted by Remy Maucherat <re...@apache.org>.
Remy Maucherat wrote:
> glenn@apache.org 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.
>
> The NamingResources object is supposed to contain all the necessary data
> to recrate the JNDI context. The question, and what I was planning to
> investigate, is why it doesn't work. I think it did in the past.
>
> I'll revert this patch when I find a better fix for the bug.
I investigated the problem as much as I could, and I cannot reproduce
the original bug.
The patch introduces wrong behavior as explained, so I am -1 for it, and
will revert it.
The original report was that the JNDI resources were disappearing after
a reload of a context using the manager.
Here is what I did to try to reproduce it:
- full recompile and start of Tomcat 4.1, after adding a user for the
manager webapp
- use of the JNDI servlet to display the naming environment of the
"examples" context (http://127.0.0.1:8080/examples/servlet/JndiServlet)
- use of the HTML interface to the manager to reload the "examples"
context (http://127.0.0.1:8080/manager/html/reload?path=/examples)
- reload was successful
- use JNDI servlet in a different browser (Moz, the first one was in
IE); result is the same as the first attempt
So I would like detailed information on:
- what is actually failing
- how to reproduce it
Thanks,
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming
ContextBindings.java
Posted by Glenn Nielsen <gl...@mail.more.net>.
Remy Maucherat wrote:
> Glenn Nielsen wrote:
>
>> Remy Maucherat wrote:
>>
>> > glenn@apache.org 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming
ContextBindings.java
Posted by Remy Maucherat <re...@apache.org>.
Glenn Nielsen wrote:
> Remy Maucherat wrote:
>
> > glenn@apache.org 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
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming
ContextBindings.java
Posted by Glenn Nielsen <gl...@mail.more.net>.
Remy Maucherat wrote:
> glenn@apache.org 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.
> The NamingResources object is supposed to contain all the necessary data
> to recrate the JNDI context. The question, and what I was planning to
> investigate, is why it doesn't work. I think it did in the past.
>
> I'll revert this patch when I find a better fix for the bug.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming
ContextBindings.java
Posted by Remy Maucherat <re...@apache.org>.
glenn@apache.org 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.
The NamingResources object is supposed to contain all the necessary data
to recrate the JNDI context. The question, and what I was planning to
investigate, is why it doesn't work. I think it did in the past.
I'll revert this patch when I find a better fix for the bug.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>