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 " 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. David ----- Original Message ----- From: "Green, Jeffrey" <[EMAIL PROTECTED]> To: "'Tomcat Users List'" <[EMAIL PROTECTED]>; "'David Wall'" <[EMAIL PROTECTED]> 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 URL. > Then prepend that with the image name (or do whatever manipulation is > necessary). I've found it tougher to actually get a webapp deployed "using > any 'name' I'd like". Hod did you get that working? > > -----Original Message----- > From: David Wall [mailto:[EMAIL PROTECTED] > 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 > http://mydomain.com/ (using the root context) or http://mydomain.com/app1/ > or even http://mydomain.com/app2/ 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 using > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -------------------------------------------------------------------------- ---- > 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 as > 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 be > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
