DO NOT REPLY [Bug 37943] - Deploying new war file does not update conf/catalina/localhost/[appname]

[bu...@apache.org]

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


mech@tngtech.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mech@tngtech.com




------- Additional Comments From mech@tngtech.com  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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org