question about the JSP hierarchy...

[Neil Mc]

Hi,

I'm a little confused about the sample code on the bottom of page 308 on HFS.

The code demonstrates the jspInit() method being overriden in a JSP declaration. Fair enough. Within this code getServletConfig() is called directly. Fair enough. However, getServletContext() is also called directly and its this call that I don't get.

If your generated servlet implements HttpJspPage, which implements JspPage, which implements Servlet.... how can getServletContext() be called direct when it is actually defined in GenericServlet (which is one-down from Servlet and therefore a peer of JspPage) ? getServletConfig is defined in Servlet, so I understand how this call is made.

Is there something going on behind the scenes that I've missed here ?

Any help, much appreciated.

Neil.

[Kathy Sierra]

Yeahhh.... good catch. Yes, there *is* something happening behind the scenes.

You're right about the interface hierarchy; we used getServletContext() because that method is inherited by the Apache implementation class:

Class HttpJspBase

java.lang.Object
javax.servlet.GenericServlet
javax.servlet.http.HttpServlet
org.apache.jasper.runtime.HttpJspBase


All Implemented Interfaces:
javax.servlet.jsp.HttpJspPage, javax.servlet.jsp.JspPage, java.io.Serializable, javax.servlet.Servlet, javax.servlet.ServletConfig

So... we just used the inherited getServletContext(). However, to be safe if you know *only* about the interfaces (which I believe is all you are supposed to know) you should probably use:

ServletConfig sConfig = getServletConfig(); //this is OK because we inherit it, as you said
ServletContext ctx = sConfig.getServletContext(); // we KNOW we can do this

The one we used:

ServletContext ctx = getServletContext(); // assumes we inherited it from the implementation class provided by Tomcat...

There is a *chance* that this is actually guaranteed by the spec, but I couldn't find it on a quick look. We're asking the JSP spec developer for more details on this. In other words, is it always safe to use getServletContext() rather than going through the SevletConfig? I'm not sure; I'm guessing if I say, "probably not". But this is DEFINITELY not on the exam.

We REALLY should have said something about this, so you're right to have been confused by that.

So, the safe thing (unless you can find it guaranteed in the spec) is to just use your config, which you KNOW is part of the API, to get to your context, rather than doing what we did--assuming the inherited getSerlvetContext(). In other words, if this is *not* guaranteed by the spec, then we just wrote non-portable code!! (bad, bad, authors!)

Bottom line: I'm not sure if it's in the spec; it is NOT on the exam, and to be safe, using your config will always work.

Thanks!
--Kathy

[Neil Mc]

Ahhh..... that makes sense. For exam purposes I'll just stick to

getServletConfig().getServletContext()

to be on the safe side.

Incidentally, if we come across a question in the exam, for example...

Does jspInit() have acess to a ServletContext object ?

(similar to coffee cram 7 qu. 4) Should that be treated as direct access (i.e. can we call getServletContext()) or indirect access (do we have acess to it via another object - in this case a servletConfig) ?

Cheers - Neil.
[ October 02, 2004: Message edited by: Neil Mc ]

[Kathy Sierra]

On the real exam, the questions will be very explicit about whether access is direct or not or through an implicit object or whatever... but to answer that question, if you WERE asked something like whether you could get a context in jspInit(), you could infer that since you DO have access to a config object, you can ALWAYS get to your context by going through config, and that getServletContext() is a convenience method provided by the class hierarchy of certain implementations.

But again, you won't have something like that where you have to wonder, "do they mean *through a method call that's inherited* or * through an implicit object* or *by going through something else that we DO inherit* or...

Although a few questions in our book are not quite as precise as they should be, I can assure you that the ones on the exam have been tested SO much, and all *real* ambiguity has been removed from the real exam--I'm very confident of that.

Again Neil, good catch

cheers,
Kathy