-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter,
On 2/16/2009 10:29 AM, Peter Flynn wrote: > and modified the sample Host element to match in server.xml > > <Host name="my.server.name" appBase="webapps" > unpackWARs="true" autoDeploy="true" > xmlValidation="false" xmlNamespaceAware="false"> > <Context path="" docBase="/var/www/xml/" > debug="9" crossContext="true"/> > <Context path="/" docBase="/var/www/xml/" > debug="9" crossContext="true"/> Yuk: #1 <Context> elements are best left in META-INF/context.xml files within each application's WAR file (or exploded WAR file). #2 <Context> elements should not set their paths (except in server.xml; please see #1) #3 <Context> elements should never set the path to "/", as this is confusing to the reader and, I suspect, impossible to reach once started. Tomcat uses <Context path=""> for the "root" web application. <Context path="/"> doesn't make any sense. #4 You are deploying the same application (/var/www/xml) twice. It doesn't sound like this is really what you want to do. #5 It looks like you are trying to deploy the same application twice to the ROOT context (see #3 and #4). Please see http://tomcat.apache.org/tomcat-6.0-doc/config/context.html > (This may be suboptimal /var/www/xml/ is where my XML/XSLT files are, > but it's unclear to me if this is actually needed at this level of the > config.) > > This worked fine to test what I am doing in Cocoon, although the server > sticks in an unwanted /cocoon/ into the URI. Now I need to add Lucene > and several other apps (via .war files) but I am having difficulty > understanding how to configure Tomcat to use multiple apps. Let's take it one step at a time. Do you have a WAR file you are trying to deploy, or is everything in /var/www/xml? > As far as I understand it: > > a) I need to make Cocoon the default app, because that's what the bulk > of the work will run through (but I'm happy to be told this is wrong). > Comments in the mailing lists indicate that this will also get rid of > the intrusive /cocoon in the URIs. The "default app" is really a vague term. If you mean that the web application hosting Cocoon should get requests to http://host/, then that is called the "ROOT web application". The ROOT webapp also gets all requests that don't get mapped to some other webapp, too (such as http://host/webappB/foo/bar when "webappB" doesn't map to a running webapp). > b) I then add the other apps in servlet-mappings in web.xml Application != servlet. web.xml declares and maps servlets. If you truly have a separate application, you should have a separate WAR file or a separate directory with all your webapp stuff. > [stop][rewind][play] > The cocoon.war was unwrapped in webapps > [stop][fast-forward][play] > > I deleted the ROOT directory in webapps; renamed the cocoon directory to > ROOT; removed the /cocoon from the httpd.conf This is exactly what you should have done. cocoon.war will be deployed to /cocoon. Re-naming it to ROOT.war will deploy it to "/". > and added this to web.xml > (and restarted tomcat5 and httpd) > > <servlet-mapping> > <servlet-name>Cocoon</servlet-name> > <url-pattern>/*</url-pattern> > </servlet-mapping> I believe Cocoon's configuration already maps Cocoon to all incoming URLs. This shouldn't have been necessary. > But accessing any URI using the virtual hostname then brought up the > Tomcat 404 error "requested resource (/what/ever) is not available. Do this: * Stop Tomcat if it's running * Remove all <Context> elements from your server.xml file. * Leave cocoon.war exploded into webapps/ROOT * Remove everything else from the webapps directory (maybe move everything somewhere else in case you need it back) * Delete everything in work/ and logs/ * Start Tomcat * Check all logs in logs/* * Come back and tell us how things went - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmZ7bgACgkQ9CaO5/Lv0PDaXQCdHWSv7olIkRzfwNbHYFcwSesq 52EAn2V4Ld0xDzpwolSjUnXrtMo29+oi =TCMJ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org