You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2003/03/28 02:08:42 UTC

DO NOT REPLY [Bug 18436] New: - Issues with ServletContextListener and JNDI

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18436>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18436

Issues with ServletContextListener and JNDI

           Summary: Issues with ServletContextListener and JNDI
           Product: Tomcat 4
           Version: 4.1.24
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: mike.vannoord@brainna.com


I'm seeing some inconsistant behavior when using a ServletContextListener in 
regards to JNDI lookups.  My ServletContextListener kicks off a process which 
needs to do some resource cleanup (it's getting pooled data connections via 
JNDI) in the contextDestroyed() method.  This resource cleanup happens to be 
taking place in a different thread than ServletContextListener is running in.

If I "reload" my application, everything works great.  If I simply remove my 
application (or shut down Tomcat), I run into problems.  Apparently the JNDI 
resources are unavailable in threads outside the main one.

It seems to me that all the Context's resources should be available when the 
contextDestroyed() method is called, but maybe that's just my interpretation of 
the servlet specs.  In any case, behavior should be consistent between an 
application reload and an application stop + start.

Taking a quick look at the code, it should just be a matter of changing the 
order of where listenerStop() is called in the stop() and reload() methods in 
StandardContext.  I'd suggest moving it directly after the filterStop() call 
but before the Lifecycle STOP_EVENT is issued.  That would more closely 
resemble a mirror image of the start() method.  But what do I know...

I'm attaching a war file which should demonstrate the behavior.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org