Hi again,
OK - here are some steps you can try out to reproduce the problem I am
experiencing - I'm hoping this will tempt someone into taking a look :-).
The problem we have is that tomcat 5.5.x (I tried 5.5.12 and 5.5.17) won't
unpack ROOT.war when it is started up, if a file called ROOT.xml is present
in conf/Catalina/localhost.
(1) Build a simple webapp, for example containing:
success.html
WEB-INF/web.xml
and place these into a war file called ROOT.war.
(2) Place a ROOT.xml context file into conf/Catalina/localhost with:
<?xml version="1.0" encoding="UTF-8"?>
<Context path="" debug="1">
</Context>
The server.xml file can stick to the defaults that you get with tomcat
5.5.17 (or 5.5.12):
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
(3) Delete any directory under webapps called ROOT, and drop the war file
into webapps.
(4) Start tomcat.
--> doesn't unpack war.
(5) delete ROOT.xml from conf/Catalina/localhost, and restart tomcat
--> does unpack the war file.
Similarly, a war file containing META-INF/context.xml will be deployed, as
long as there isn't a file called ROOT.xml inside conf/Catalina/localhost.
The problem for us is that we would like to deploy the war on different
servers, offering different JNDI resources. So shipping a war file
containing a context.xml isn't an option for us.
I have searched the mailing lists for a solution to this problem, but so
far without luck. There was a useful mail trail last year that resulted in
a document being placed in bugzilla containing instructions on how to
deploy a root app using tomcat's manager (
http://issues.apache.org/bugzilla/show_bug.cgi?id=35063). However our
production environments don't support the manager app.
I have tried tweaking some of the parameters. For example, if I set a
docBase of ${CATALINA_HOME}/webapps/ROOT, I'll see a warning in the logs
saying that "a docBase [...] inside the host appBase has been specified,
and will be ignored" - which at least shows that ROOT.xml is being parsed.
Likewise, changing the the docBase to point to a directory outside of
${CATALINA_HOME} doesn't solve the problem.
(Am I right in thinking docBase *isn't* a required attribute? If I leave
this out of ROOT.xml, and expand the war file manually, the ROOT app will
pick up JNDI resources correctly).
I've also played with some of the <host> attributes in server.xml, e.g.
adding deployOnStartup="true" to server.xml (it is true by default), or
setting autoDeploy="false", but none of these tweaks helped.
So - is it a bug (or a feature?!) that ROOT.war won't unpack if ROOT.xml is
already present in conf/Catalina/localhost?
Thanks for any help,
Andy Cooke
----------------
Hi there,
We have been finding it difficult to persuade tomcat (5.5.12 and 5.5.17) to
unpack a ROOT.war file, either when starting up tomcat from scratch, or
hot-deploying.
We *were* able to get tomcat to expand the war file if it contains a
META-INF directory containing a context.xml file. However if this
directory is missing from the war, and instead a ROOT.xml context file is
present in conf/Catalina/localhost before starting tomcat - the war file
*isn't* expanded.
Our server.xml file contains the default settings (unpackWARs="true"
autoDeploy="true").
Any ideas? We would rather not include context.xml files in the war, as
the same war file will be deployed on different servers, which require
different JNDI resources.
thanks
Andy Cooke
-----------------------------------------
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
