-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/12/2013 14:58, Christopher Schultz wrote: > My experience has been that, specifically with JNDI resources, the > resource is not touched during the reload procedure. So, for > instance, if the JNDI name doesn't change but the URL does, the > application does in fact require a re-deployment. Is that > intentional behavior, or just a result of the implementation we > happen to currently have?
You need to be very clear whether you are talking about a reload or a redploy. You also need to specific about the Tomcat version as much of the recent work was around cleaning up many of the ambiguities that exist is most versions in use today. In summary, a reload: - - calls stop() then start() on the same Context object - - re-reads web.xml - - doesn't re-read context.xml - - is triggered by a change in web.xml, from the Manager app or via JMX - - can also be triggered by a change in a reload resource whereas a redploy: - - calls stop() then destroy on the current context - - re-reads context.xml and creates a new context object - - is triggered by a change in context.xml, WAR file or DIR (timestamps) - - can also be triggered by a change in a redeploy resource Looking at JNDI and reloading: - - the Context keeps the same NamingContextListener - - the NamingContext is renewed - - the NamingResources has stop()/start() called - - NamingResources.stop() should close any resources that can be closed > Is it reasonable to modify Tomcat such that the JNDI resource is > disposed and re-built during an application reload? This should be what happens although a fair amount of information is retained. > Of course, this would only make sense for resources defined in a > webapp's Context/Resource, not for global resources. This would > also make it possible to package JDBC drivers along with the web > application and not cause ClassLoader pinning. Class loaders should not be pinned if correctly used. > If the above change were made, a redeployment would not be > completely necessary, even if it does turn out to be the best > solution. If a URL (or any other config of a JNDI resource) changes then that is a change in context.xml and that has to result in a redeployment. Trying to figure out if a change in context.xml should trigger a redeploy or a reload is just far too error prone. Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSs0GjAAoJEBDAHFovYFnnEFcQALKczvkUtVgmF/4g5Z44buEM jMftq/pWiis0ks64dzzictVkOY3L8r9F1YpqWzDcTceJHBT4QCdaD2koNSDu7lvc 4EZuiLA+SfyucmWrS/G1v8u7Mqufkli/ba2Y9s7WF+j74So+46qDzT5SNwGErgGa yzvrqG81U3am1iXcAfyEkQlUllYIbRQNaV1axLeKKX8jL61v85v8z5c8B9svEXit HYQKFp+S+b5Azxlv45CDF6X/xPjoH7dbb1zAe1JVIgJ3b8Q8m5cPspV5zXZa0JwM gB/B92PMTT/vswpgPQXLkiSfnTzzj6smoaPKPC1qRStyyr19OY0I5J9nhLldQ63j mRlvvIU8oXN9CHAvCvRUJ2boindIRu30JfOU1tkGF+09sAnPgRexz/B3KaMmBqVJ L14DyHJF+ylapodmOH33m0RXzg5NYOH9ZjpYQfKEZAJ9IUTX6Mpr+N8kmwdNriWh q6aj0WmBdHRb8AyaFzTLggdtS90CAFRPsrR3kSwOwJ03w7aU0xUysDdTBiMxz9cQ EBAVtX7bBCLUsSvJDJi8ymNr3p92+yDZ+64IXBS/Dnjeaza+2vfxvRL7h/rr3cbg 5bzkZgzQl9KHaw9y1g4Lwnl55p5y+TsQt9rdZpdwQZxhaU4uAAfHPWj46RyHq+09 3hxHhSYsFsQPTlQyQrKl =B8fV -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
