wood burning stoves*
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes JSP behaving badly! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "JSP behaving badly!" Watch "JSP behaving badly!" New topic

JSP behaving badly!

Simon Ingram
Ranch Hand

Joined: Nov 30, 2003
Posts: 171
Hi guys,

I have a simple servlet with a simple JSP. The JSP only prints the following:

Beer Selection

It should print!

and I have no idea why the other information is not printed. I have been trying to figure this out for so long that the code is swimming in front of my eyes! Would some kind soul help?

Here is the JSP:

And finally here is the Tomcat terminal showing the progress:

24-Apr-2006 19:40:43 org.apache.catalina.startup.Catalina start
INFO: Server startup in 3703 ms
BeerSelect: New Session
BeerSelect: step 1
BeerSelect: set attributes
BeerSelect: step 2
BeerSelect: step 3
BeerSelect: step 4
result: top
result: step 01
result: step 001
result: step 1
result: step 2
result: step 3
BeerSelect: request forwarded
ServletQ2: q1 = no styles: 12
ServletQ2: form2a
ServletQ2: form2a forwarded
Marc Peabody
pie sneak

Joined: Feb 05, 2003
Posts: 4727

View the source of your html page from the browser. See if there is anything else there.

A good workman is known by his tools.
Akshay Kiran
Ranch Hand

Joined: Aug 18, 2005
Posts: 220
the only way that stuff in the script could have been omitted would be if
scripting was disabled in the DD,

but that is still no reason why the control should return to the forwarding servlet after the request has been forwarded once

"It's not enough that we do our best; sometimes we have to do<br />what's required."<br /> <br />-- Sir Winston Churchill
Charles Lyons
Ranch Hand

Joined: Mar 27, 2003
Posts: 836
the only way that stuff in the script could have been omitted would be if scripting was disabled in the DD

That wouldn't do it - if scripting was disabled in the deployment descriptor and scripting elements are present in the JSP, a translation error occurs.

but that is still no reason why the control should return to the forwarding servlet after the request has been forwarded once

This is a common mistake: control always returns to the servlet which invoked the RequestDispatcher. All the RD does is provide a method which can be invoked to execute another component in the container. Once the forward/include has completed, the RequestDispatcher's method returns and control passes back to the calling component - just with any other Java method. So no, in fact it would be suspicious if control wasn't passing back to the servlet.

This is a strange problem though - I can't see any reason why this shouldn't work correctly. The only thing I can think of is that an exception is being thrown in the scriptlet, but the response has already been committed so the container can't take any action other than to abort the processing of the page. However, I wouldn't then expect the servlet to continue processing - I would expect it to throw an exception which would be traced in the log instead.

Have you tried condensing the executable code by commenting out all lines in the scriptlet and then putting them back one-by-one? If you look at the actual source code for the returned HTML page, does it contain the closing </body> and </html> tags?

If all else fails, try looking at the actual generated servlet source code - you'll find this under Tomcat's working directory (e.g. /work) and then keep looking in the directories until you find org/apache/jsp/ under your domain. Then for a JSP called form2a.jsp you will have a form2a_jsp.java file... that's the generated source code. Often it will tell you much more about what's going on than you might think.

Anyway, please post back with any more information or success, because this is just a little bewildering!

Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340 / Amazon Amazon UK )
Simon Ingram
Ranch Hand

Joined: Nov 30, 2003
Posts: 171
Hi guys,

Well, it gets more confusing! As Marc suggested, I checked the source in the browser and there were no surprises, everything was there, but when I checked the generated source in Tomcat, was it strange! Take a look!

Here is an extract of the generated source from another JSP that is almost the same.

It looks like the scriptlet identifier "<%" is not interpreted in the first case. As I say, I've been fiddling around with this for ages. I am absolutely baffled. Any ideas here would be great!
Akshay Kiran
Ranch Hand

Joined: Aug 18, 2005
Posts: 220

I was under the same impression until I was confused by the HFSJ

here's an excerpt from page 205

Q. How come you didn't talk about the RequestDispatcher.include() method?
A. It's no on the exam, for one thing. for another, we already mentioned that it' not used much in the real world. But to satisfy your curiosity, the include() method sends the request to something else (typically another servlet) to do some work and then comes back to the sender! In other words, include() means asking for help in handling the request, but it's not a complete hand-off. It's temporary, rather than permanent transfer of control. With forward(), you're saying, "That's it, I'm not doing anything else to process this request and response." But with include() ...

Bold and Italics are NOT mine.

As you see, the tone is comparative- they say- "it's temporary rather than..." making the readers to assume forward() is permanent!!!

overall I think the HFSj doesn't do a real professional job. It's different story what people like to read and all that "stuff that sells" part.

But hey, if I use a reference guide, I need it to be without any ambiguities. The book as such is LOW LOW LOW on clarity, lots of word play, although it might do well as an exam guide, it will never serve to be a professional reference- you need to read the whole thing when you need just one bit of info. Anyway, my intent was not to offend or censure, but I'm just remarking that there's a need for more balance in the book.

no offence intended, but I wasn't impressed, maybe it wasn't for me after all...
Simon Ingram
Ranch Hand

Joined: Nov 30, 2003
Posts: 171
Hello folks,

Just to let you know that I have managed to get this thing working and I hope the solution may help some of you out there! The problem was the small "s" in the cast to string in line 3 below. Once this is corrected the whole thing works, but this is not really the point. The point is that I only got the error diagnostic by changing the name of the jsp and recompiling the servlet that dispatches it. Despite recompiling the servlet with the old jsp and despite changing the old jsp itself, I did not get any error diagnostic, it was only by creating an identical jsp with a different name, that I was able to trace the problem. I realise this is not exactly exam related and is, to be frank, clunky and irritating, it may help you when you come to actually start building servlet/jsp applications. Anyway, I would like to thank Kiran and Charles for helping me to figure this out.

all the best

Charles Lyons
Ranch Hand

Joined: Mar 27, 2003
Posts: 836
Such a strange problem... one would think that this would generate a compilation error.

Looking at your translated source code above though, are you sure you originally saved the file in UTF-8 (or similar) plain text? If you haven't, the translator might actually read your page incorrectly (for example, if it's in UTF-16 or in the "Unicode" format in Windows Notepad/Wordpad) and therefore doesn't see <% as <%, but instead as some other weird characters or the "< % " you experienced. This would explain the first two bytemark characters which are supposed to indicate high- or low-endian encoding (if memory serves right, the value is 0xFFEF, or that might be 0xFFFE) and should be removed when examining the correct document format type. I experienced this problem with a client application a few years ago - it was very sensitive about file formats!

This is the point of setting the page encoding using the page directive, but best off is to check that only UTF-8 plain text is being used.

If you didn't save in the right encoding to begin with, the translator and compiler won't recognise anything you write in the document, so won't parse the scriptlet, and certainly won't go to translate it. This actually explains the problem completely, and it would appear the lowercase 's' is a misnomer (as if the encoding were correct it would have been reported).

Out of interest, could you check the encoding on the page that's working, and then save it in a different UTF-16 or "Unicode" encoding and try again?

It is sorta covered in the JavaRanch Style Guide.
subject: JSP behaving badly!
Similar Threads
to support both get and post methods in one servlet
help needed with tomcat/requestDispatcher - example form HeadFirst servlets and jsp
Why this EL code part is not working
Compiling result.jsp (page 89 HFSJ)
getRequestDispatcher error in servlets