Howdy,
One thing I would, try, then is to have a packed WAR without a
corresponding Context entry in server.xml.  Just the default settings,
and let tomcat handle it.

Yoav Shapira
Millennium ChemInformatics


>-----Original Message-----
>From: Robert L. Brueckmann [mailto:[EMAIL PROTECTED]
>Sent: Thursday, December 18, 2003 9:43 AM
>To: Tomcat Users List
>Subject: RE: include/WAR
>
>Yoav, Thanks for the reply...yeah I'm a bit long-winded at
times...sorry
>'bout that.  :)
>
>Anyways, to answer a few of your questions...my directory structure is
as
>follows...I have a directory called 'application' and in 'application'
I
>have a header.jsp file...then under 'application' I have 5
subdirectories
>which contain the 5 functionalities of the software.  In these
>subdirectories, all filed have the jsp:include file="../header.jsp"
call in
>them to pull header.jsp from the 'application' directory, so they all
share
>this one common header file.  This works perfectly when I drop the
actual
>expanded directory structure in the webapps directory and set the
docBase
>in
>my server.xml to the parent directory of 'application'...but as soon as
I
>war everything up and drop the war in the webapps directory and set the
>docBase to the war filename in server.xml, I get blank pages in any
call I
>make to any of the files in any of the subdirectories in the
application
>folder.
>
>I also have a few files in the 'application' directory that have
>jsp:include
>file="header.jsp" in them and those all work perfectly in war format
and
>unpacked format...so I looked at the servlet log in the log directory
of
>tomcat and I have a bunch of FileNotFoundExceptions and it shows tomcat
>trying to access the file like this:
>
>"/application/import/../header.jsp"
>
>It's like its trying to access header.jsp in a subdirectory of import
with
>the directory name of '..' instead of using those '..' to traverse up
one
>directory and look for the file.
>
>Very strange stuff.
>
>I'm using tomcat 4.0.3 (I know it's old but it's too late in the
>development
>process and too close to the next release date to change the version of
>tomcat we're using (which we plan on doing in the next developmental
>cycle...but for now, this is really just curiosity...if we are forced
to
>leave it expanded, then so be it, but for out installation process,
using
>the WAR would be SO much nicer...and if we can work around this last
bit of
>trouble, we'd be in the clear.) )
>
>As for the getRealPath...we don't use that call often, but we have a
>section
>of the application where we import external files the user tells us the
>filename of and I guess we're just doing it incorrectly...I'll look
into
>your suggestions on the replacement of the getRealPath...thank you for
all
>your help.
>
>Rob
>
>-----Original Message-----
>From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
>Sent: Thursday, December 18, 2003 9:19 AM
>To: Tomcat Users List
>Subject: RE: include/WAR
>
>
>Howdy,
>Not a big fan of short sentence, huh? ;)
>
>>Is this a tomcat issue or is this a jdk 1.4 issue where the
jsp:include
>>calls in my jsp pages that include files from other directories do not
>work
>
>It's probably neither a tomcat issue nor a JDK 1.4 issue.  By other
>directories, do you mean outside the webapp?
>
>>when the webapp I'm deploying is in WAR format?  I have a context
setup
>for
>
>Packed or unpacked WAR?  Either way, your webapp should not use
>getRealPath calls: replace them with ServletContext#getResource or
>getResourceAsStream.
>
>>getRealPath() calls break as well...is there any way to force Tomcat
to
>>autoexpand my WAR file even though I'm setting it up with a context
and
>
>Yes, set the unpackWARs attribute to true for the Host element where
>your Context is.  You can verify that your WAR is unpacked by looking
at
>the filesystem.  Remember, if you're using tomcat 5 it's under a
>different directory from tomcat 4.
>
>>realm in server.xml?  Or am I stuck going through my entire
application
>and
>>giving absolute paths to all my jsp:include files and writing
something
>to
>>create temporary directories to replace my getRealPath() situations?
>
>You should replace your getRealPath calls anyways.  You should have
>relative paths for your inclusions anyways.
>
>Yoav Shapira
>
>
>
>This e-mail, including any attachments, is a confidential business
>communication, and may contain information that is confidential,
>proprietary
>and/or privileged.  This e-mail is intended only for the individual(s)
to
>whom it is addressed, and may not be saved, copied, printed, disclosed
or
>used by anyone else.  If you are not the(an) intended recipient, please
>immediately delete this e-mail from your computer system and notify the
>sender.  Thank you.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to