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 otherJava 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 / AmazonAmazon UK )
Joined: Nov 30, 2003
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!
Joined: Aug 18, 2005
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...
Joined: Nov 30, 2003
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 Simon
Joined: Mar 27, 2003
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?