DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37943>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37943 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] ------- Additional Comments From [EMAIL PROTECTED] 2006-01-04 23:52 ------- I guess the real problem behind this issue is the way Tomcat handles META-INF/context.xml (a problem that exists since releases (at least 5.0.28, but I guess even back in 4.1.x) and still in 5.5.x. META-INF/context.xml is "only" taken into account, if a webapp is deployed from a .WAR and unpacked. http://tomcat.apache.org/tomcat-5.5-doc/config/host.html says for autodeployment: " Any subdirectory within the application base directory that appears to be an unpacked web application (that is, it contains a /WEB-INF/web.xml file) will receive an automatically generated Context element, even if this directory is not mentioned in the conf/server.xml file. This generated Context entry will be configured according to the properties set in any DefaultContext element nested in this Host element. The context path for this deployed Context will be a slash character ("/") followed by the directory name, unless the directory name is ROOT, in which case the context path will be an empty string ("")." This means that whenever the webapp is unpacked already for some reason, and for some reason (deleleted, incomplete deployment, war locking...) the content of the context deployment descriptor in /conf/Catalina/localhost doesn't match the one in META-INF/context.xml in the webapp it is simply not taken into account. Instead the DefaultContext is used, ignoring the docBase etc. I stumbled upon this releases ago and I think Tomcat should be enhanced to first look for a META-INF/context.xml in this case. Of course, some fixes had been made, but I guess it was never solved completely. Actually this has practical problems in production environments. E.g. we use a symlinked webapps directory in order to have to deploy a webapp only once, have patches available for all, have only one physical location, etc. in a multi Tomcat instances loadbalanced environment. In production we also don't use autoDeploy, only deployOnStartup. We deploy only WAR files, as real drop-in deployments. Moreover we have important information in META-INF/context.xml -> e.g. JNDI resource links that need to be resolved and taken into account when the context starts (nothing that happens when just DefaultContext is used, and something that causes our DB connection to fail by a JNDI lookup exception). In effect this has the following impact (on Tomcat 5.0.28, but I see no change that could cause 5.5.x to work differently): 1. clean webapps directory filled with just .WAR files, (/conf/Catalina/localhost wiped, too.) Tomcat #1 starts up, deploys on startup, unpacks war files, meanwhile the META-INF/context.xml gets renamed/copied to that Tomcat instance's /conf/ as it should. Now the problem arises... Tomcat 2..n starts up nearly simultanously, .WAR is already unpacked (delay), hence Tomcat 2..n will ignore META-INF/context.xml, just use DefaultContext, JNDI resource unavailable, etc. -> webapp not really "successfully" deployed, eventhough it is deployed with incomplete context setup. Actually it just does what the docu says, eventhough it's not a good idea... -> Workaround: copy the /conf/Catalina/localhost/<yourapp>.xml of Tomcat #1 to Tomcat #2..#n and restart the context on all other Tomcat instances. Not nice, but works. Usually I make /conf/Catalina/localhost/*.xml readonly after the initial deployment for all instances. This way when I undeploying/hot deploy a context the context.xml won't get deleted (and usually META-INF/context.xml stays the same, even if you deploy new webapp versions). Thus this problem occurs only the very first time. Still annoying... Could be solved by always prefering META-INF/context.xml, if available. In fact I assumed this deployment descriptor was introduced for this reason, so why not always obey its preciding information? Of course, one could still ignored docBase and assume the .WAR equals the directory/context name, eventhough it would be nicer if even this information would be used for unpacking. But it would help already to always use the META-INF/context.xml if that is easier to implement. Probably one should change this bug to "ENHANCEMENT" to get .WAR deployment with META-INF/context.xml consequently implemented in future versions and make them work for some more complex installation scenarios without tweaking. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
