Unfortunately, this is expected behavior. There is a bug about it at http://nagoya.apache.org/bugzilla/ if you want to search for it. The docs mention this as the expected behavior, but don't give a reason why it should be that way.

Basically, if you name a <Context ....> element, you will have to make sure you expand the .war yourself before starting Tomcat.

Any Tomcat developers want to pipe in and explain why the behavior is this way?

Jake

At 09:40 PM 10/24/2002 -0500, you wrote:
I recently added a new context to server.xml so that I can set up a
database
connection pool resource for my webapp.

The webapp was deploying/running well prior to adding this context.

With the context added, starting Tomcat produces an error for that app
context:

java.lang.IllegalArgumentException: Document base
/usr/local/tomcat/webapps/myapp does not exist or is not a readable
directory
at
org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.jav a:193)

This suggests that docBase directory is expected to exist at start.
Without that context in server.xml, the war unpacks and
creates its directory.

The context looks like this:

<Context path="/myapp" docBase="myapp"
reloadable="true" crossContext="true>
... resources here ...
</Context>

If I change the docBase to "myapp.war", the application loads and runs
properly, db conn pooling works a treat, BUT
the war isn't unpacked at all.

The behavior I want is to have the war get unpacked ( as it was before
) so that I can serve some of the static content
directly from Apache httpd, but still package/deliver/deploy the webapp
as a war to Tomcat.

Any thoughts as to why this is happening / how to solve?

Thanks.

- Ken


--
To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>

Reply via email to