tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Wall" <>
Subject Re: Webapp names and paths within JSPs for images
Date Thu, 08 Jan 2004 21:10:45 GMT
Well, right now we have a hard-coded app name for the paths (when we can't
rely on relative path names) in the image tags since making all image tag
path names dynamic would be a bit of a pain, plus it would make those images
not appear in tools like Macromedia that need to be able to resolve the
paths locally.

It seems that we're either doing this "wrong" or the pretense that webapps
can be deployed using any name chosen at deployment time simply is not true.
I would not be surprised since I find a lot of plumbing type work is still
necessary when using JSPs.  Another one is having to encode all output so
it's HTML safe, including data values that appear in INPUT value="abc" type
tags as well as SELECT and TEXTAREA when 99.99% of the time we want our
output to be HTML safe.  While it's a pain coding-wise, there's also no
standard way to do that encoding so we all write our own routines that
convert " to &quot; and the like.  It just seems like there's a lot more
marketing to JSPs right now than is delivered considering how mature
Java/JSPs are already.


----- Original Message ----- 
From: "Green, Jeffrey" <>
To: "'Tomcat Users List'" <>; "'David Wall'"
Sent: Thursday, January 08, 2004 12:53 PM
Subject: RE: Webapp names and paths within JSPs for images

> I'm running into the exact same issue.  It seems that you could use
> HttpServletRequest.getContextPath() or parse through
> HttpServletRequest.getRequestURI() to get the root-relative path of the
> Then prepend that with the image name (or do whatever manipulation is
> necessary).  I've found it tougher to actually get a webapp deployed
> any 'name' I'd like".  Hod did you get that working?
> -----Original Message-----
> From: David Wall []
> Sent: Thursday, January 08, 2004 3:43 PM
> To: Tomcat Users List
> Subject: Webapp names and paths within JSPs for images
> In theory I should be able to take my webapp (starting with the base
> directory that contains the WEB-INF subdirectory) and deploy it using any
> "name" I'd like, so I could easily deploy the same webapp with URLs like
> (using the root context) or
> or even etc.
> However, JSPs can include files using the "/" root to indicate I'm talking
> about a file at the top of the webapp directory and that works fine.  But
> images need to include URLs that that aren't processed by tomcat (so it
> doesn't know about the webapp's "base" directory), so I have to use names
> like "/images/image.gif" or "/app1/images/image.gif" or
> "/app2/images/image.gif" depending on where the webapp was actually
> deployed.
> While I can use relative paths for such images much of the time, when
> servlets that redirect/forward or whatever, the "current directory" is not
> always the same, so you can't just use "images/image.gif" or
> "../images/image.gif" to make it work.
> How are people coding their JSPs and servlets that return IMG tags so that
> the images can always be defined without including the webapp path name?
> Thanks,
> David
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> --------------------------------------------------------------------------
> This message is intended only for the personal and confidential use of the
> designated recipient(s) named above.  If you are not the intended
recipient of
> this message you are hereby notified that any review, dissemination,
> distribution or copying of this message is strictly prohibited.  This
> communication is for information purposes only and should not be regarded
> an offer to sell or as a solicitation of an offer to buy any financial
> product, an official confirmation of any transaction, or as an official
> statement of Lehman Brothers.  Email transmission cannot be guaranteed to
> secure or error-free.  Therefore, we do not represent that this
information is
> complete or accurate and it should not be relied upon as such.  All
> information is subject to change without notice.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message