0

Hello there,

I have a JSP page that has a couple of images in, when I type the address of the JSP directly in my browser the page loads, with images and all. But when I go the page, through my servlet [RequestDispatcher.forward()] the page loads but the images are not displayed?

Now I don't know how that works, the code stays the same and the locaiton of the images stay the same. So i.e. JSP pages act diffirently if you go through a servlet and if you go directly to it by just typing the address in the browser. Why is this?

I'm also struggling with a normal button in the JSP page, when clicked, invokes some javascript on it and forwards you to a static HTML page, this button isn't working either...

I'm struggling my ass of just to load images, that's rediculous...

Thanks in advance!

4
Contributors
12
Replies
14
Views
6 Years
Discussion Span
Last Post by javaAddict
0

Have you tried inspecting the page source in both the cases? Do you see a difference in the image paths? Are you using relative or absolute path location for loading your images?

0

I use a relative path for the images... The code does not change at all no. What I think it might be (and correct me if I might be wrong) but JSP pages get compiled into servlets that are stored in a 'who-knows-where' folder under Tomcat. So if that's the case, the servlet will not pick up the images since I'm using a relative path...?

But what then of the button?

0

If the "relative path" is relative to system and not to your web application then your assumption is right. Are these images part of your application structure, or you pulling them form different location on your system?

0

It's part of my application structure, if I'm understanding you right here. I'm using Tomcat, so the images are located under the'webapps/ROOT' folder...

Any ideas?

0

> The code does not change at all no

When I mentioned page source, I was actually talking about the generated HTML source. If you inspect the generated HTML, you should be able to find out *why* the images are not rendered based on the path used.

Anyways, AFAIK, relative paths are a problem because they depend on the current context i.e. a page served using the URL `http://localhost/app/jsp/first.jsp` would have a different context (and hence the notion of "current directory/path") from the one served using `http://localhost/app/someservlet`. To test this out, change the 'forward' to 'redirect' and the images should again show up on the page.

Almost all real world websites use "absolute" paths for providing image sources of the form <img src="${IMG_ROOT}/daiblo.jpg" /> where IMG_ROOT holds the location of the image source. It can be either located on the same server (i.e. IMG_ROOT=/images) or be a completely different site (IMG_ROOT=http://flickr.com/dean/images).

0

May be this time you can skip the servlet part and the RequestDispatcher. I don't know if it will work, but instead of submitting to the servet you can submit directly to he page you want, and put scriplets in the page.

Assuming you submit directly to a page. Then in that page you can put the java code and then display the html code

0

The reason why I'm using the RequestDispatcher, is that I have a servlet that does database queries, and then stores data in variables that then gets forwarded to the JSP page using the RequestDispatcher...

Anyways, I got some more information,
This is the code that comes directly out of the JSP page for the images:

<img src="Images\Header.png">

And this is the code in the servlet after the JSP page has been converted:

out.write("<img src=\"Images\\Header.png\">");

So as you can see, the url stays the same. Which frustrated me the most...

Just a quick question, can having my servlets and JSP in certain packages and certain ones that are not in packages have any affect on how images are displayed?

0

Ah! I found the reason for this error, atlast!
This is a snippet out of a ebook I downloaded:

"Although a servlet can forward the request to an arbitrary location on the same
server, the process is quite different from that of using the sendRedirect method
of HttpServletResponse. First, sendRedirect requires the client to reconnect
to the new resource, whereas the forward method of RequestDispatcher is
handled completely on the server. Second, sendRedirect does not automatically
preserve all of the request data; forward does. Third, sendRedirect results in a
different final URL, whereas with forward, the URL of the original servlet is
maintained.
This final point means that if the destination page uses relative URLs for images
or style sheets, it needs to make them relative to the servlet URL or the server root,
not to the destination page’s actual location. For example, consider the following
style sheet entry:
<LINK REL=STYLESHEET
HREF="my-styles.css"
TYPE="text/css">
If the JSP page containing this entry is accessed by means of a forwarded request,
my-styles.css will be interpreted relative to the URL of the originating servlet,
not relative to the JSP page itself, almost certainly resulting in an error. The simplest
solution to this problem is to give the full server path to the style sheet file, as follows.
<LINK REL=STYLESHEET
HREF="/path/my-styles.css"
TYPE="text/css">
The same approach is required for addresses used in <IMG SRC=...> and
<A HREF=...>."

So my last question before this thread gets marked as solved, is that if the location of my images on my system is "C:\Program Files\Apache Group\Tomcat 4.1\webapps\ROOT\ContactKeeper\Images" ....what would my full server path be?

0

Ah! I found the reason for this error, atlast!
This is a snippet out of a ebook I downloaded:

Well, I did explain the same thing in my previous post:

Anyways, AFAIK, relative paths are a problem because they depend on the current context i.e. a page served using the URL `http://localhost/app/jsp/first.jsp` would have a different context (and hence the notion of "current directory/path") from the one served using `http://localhost/app/someservlet`. To test this out, change the 'forward' to 'redirect' and the images should again show up on the page.

what would my full server path be?

Assuming your application root is: http://localhost/ContactKeeper, the image path should be /ContactKeeper/Images otherwise if your application is the default application deployed (i.e. accessed using http://localhost), then /Images should do the job.

0

Thanks s.o.s, the way you explained it I didn't quite understand so well. I didn't know that the URL stays the same (the servlets url) if you get forwarded to JSP page through a servlet. So that little information in the book helped me tons.

Otherwise thanks for your help, I really appreciate it!

0

Off topic, you may consider to look up some what up-to-date version of Tomcat. Version 4 was dropped long time ago. My friend "pidster" would go berserk if he seen you using it. Latest version is 7, supported version are 5 & 6, so if you not for the hotest stuff you should at least use version 6

0

The right way would be to use servlets but there is another way. Although it is not recommended by some, (I am not one of them, I usually use java in jsp pages), you can call your java methods from a jsp. If you say that the RequestDispatcher doesn't work here is another example.

Assuming that you have a page with a form and input fields and stuff. Just submit to the jsp page you want:

page1.jsp

<form action="page2.jsp">

</form>

page2.jsp:

<%
// get data from request:
String param1 = request.getParameter("param1");
...

// do some stuff

SomeClass sc = new SomeClass();
SomeObject [] obj = sc.getData(param1,....);

// display the jsp page:
%>

<body>
.....
</body>
</html>

Try to keep as little as possible the java code. Just limit your self to getting the input from request, calling methods and displaying data.

You can also get to that page by a link:

<a href="page2.jsp?param1=123123&param2=123213">
Some Link
</a>
This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.