Anyone have this problem?

----- Original Message -----
From: Kit Cragin <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Sent: Tuesday, April 04, 2000 12:20 PM
Subject: referencing resources within a web application


> I am not sure if the following is an Orion quirk, an oversight in the
> servlet 2.2 spec, or something that has just not been thought about yet...
> but I am having a problem with consistently referencing a resource from a
> .jsp within a web application via Orion.
>
> Assume I have a web-app "test" that has the following directory layout:
>
> test/
> test/WEB-INF/
> test/WEB-INF/web.xml
> test/images/
> test/images/test.gif
> test/stuff/
> test/stuff/page.jsp
>
> and that page.jsp has this html code:
>
> <html><body>
> <!-- #1 -->
> <img src="/images/test.gif"/><br/>
> <!-- #2 -->
> <img src="images/test.gif"/><br/>
> <!-- #3 -->
> <img src="/test/images/test.gif"/><br/>
> <!-- #4 -->
> <img src="../images/test.gif"/><br/>
> <!-- #5 -->
> <img src="http://localhost/test/images/test.gif"/>
> </body></html>
>
> For the case in which I have test/stuff/page.jsp as a welcome-file in
> web.xml, <img> tags #2,3,5 properly display the image when browsing (i.e.
> http://localhost/test/)
>
> For the case in which I directly address page.jsp in the browser (i.e.
> http://localhost/test/stuff/page.jsp), <img> tags #3,4,5 work.
>
> This is inconsistent. Ideally, I would like #1 or #2 to work in both cases
> (in fact section 9.4 of the servlet 2.2 spec seems to indicate #1 would
> work). This would allow for maximum maintainability. For instance, #3
means
> I have to change all the references in all the JSP's should the name of
the
> application change; #4 means I have to change all the references if I move
a
> JSP within the application. #5, means I have to change all the references
if
> I move application to a different server.
>
> Now, most of the time users are redirected to the .jsp files in my
> architecture anyway, so method #2 is fine. But.... I still regard this as
> inadequate since that may not always be the case.
>
> Is there something I missed? Any ideas?
>
> thanks,
>
> Kit Cragin
> VP of Product Development
> Mongoose Technology, Inc.
> www.mongoosetech.com
>
>
>
>
>


Reply via email to