> --- Glenn Nielsen <[EMAIL PROTECTED]> wrote:
> > It sounds like you are referring to how the Java source code
> > for a JSP is generated. This is based on the JSP spec and
> > the vendors implementation of it. If you are using Tomcat
Somewhat; while I'm most particularly interested in the taglib
object model, I imagine it'd only make sense in the context of the
general jsp object model.
> > you might want to ask on the tomcat-user or tomcat-dev
> > lists if such a thing exists for Jasper which implements
> > JSP pages in Tomcat.
> >
> > If you are interested in writing custom tags the JSP
> > spec is your best source of information.
The spec does cover this topic, specifically in chapter 11, the
JSP Container, and chapter 12, the Core API, it's a bit too much
trees, not enough forest. Chapter 12 especially discusses each of the
various objects but doesn't provide a coherent overview of how they're
typically set up and invoked. Likewise, chapter 13, the Tag Extension
API, details each of the objects, but doesn't give a summary of how
the objects are set up and invoked.
Don't get me wrong, I live sun's specs, they're a dream compared
to most other vendor docs, but I'm still looking for something a bit
more organizational in approach.
On Mon, Apr 26, 2004 at 07:16:11AM -0700, Derek wrote:
> Of course, there are JavaDocs available for JSP in Tomcat:
>
> http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jspapi/index.html
Yup, I'm looking for something that would discuss these objects
and how they interact with each other and with their container. For
example, in the servlet world what I'm looking for would look sort of
like this:
1) The browser sends a request for a given URL to the servlet engine.
2) The servlet engine checks the URL mappings which are defined in
each webapp's WEB-INF/web.xml to see which servlet should answer the
request.
3) If that servlet hasn't been invoked before, the servlet engine
instantiates the servlet class, otherwise it gets the existing instance
of the servlet class.
4) When a servlet is first instantiated, the engine invokes
servlet.init() method, passing in a ServletContext object that
contains the servlet engine configuration information. The servlet's
init() method does any setup necessary. If it can't do the setup
necessary, it can throw ServletException to tell the engine
something's wrong.
There's a corresponding servlet.destroy() method that gets called when
the servlet engine is shutting down or otherwise taking the servlet
out of service.
5) The servlet engine wraps the incoming request in an
HttpServletRequest object, which includes properties for various
headers and attributes, parameter parsing, methods for using the
servlet engine session and other scaffolding, and the input stream of
the request.
The servlet engine wraps the output stream in an HttpServletResponse,
which includes the output stream, properties for setting response headers,
and controlling how output sent to the output stream will be buffered, and
the output stream itself.
6) The servlet engine invokes the servlet's appropriate doFoo() method,
which is usually doGet() or doPost(), but depends on what HTTP action
the request specified. The HttpServletRequest and HttpServletResponse
are passed in as parameters in the method call to doFoo().
Note that the servlet's doFoo() methods MUST be multi-thread-safe,
since they will be hit by multiple threads simultaneously. In a
nutshell this means that the servlet shouldn't touch any instance
variables (unless you know what you're doing). Multi-threaded
programming is not trivial to explain, but there are several tactics
that the servlet spec is designed to make it easier, we'll get into
those later.
7) The servlet can do whatever processing it needs to do, and then
send back response headers by using HttpServletResponse's setHeader()
method, and send back HTML using the java.io.PrintWriter returned by
HttpServletResponse's getWriter() method.
Note that generally you have do any header setting before you start
sending output back through the PrintWriter. This is because the
HttpServletResponse object is modeling the underlying process, and to
a degree obscuring it. Normally with HTTP you send back to the
browser a set of header lines, followed by a blank line as a
separator, followed by the body content (the result looks much like a
typical email).
A lot of actions, like client-side redirects, are handled by sending
specific headers back to the browser. You can't send body content
without sending the blank line separator. Once the blank line is
sent, you can't send any more headers. So do any header manipulation
and figure out if you'll need to redirect before you start sending
body content to the browser. If you mess this up, various methods
like response.sendRedirect() will throw IllegalStateException.
Note: Servlet engines may buffer body content output, but you can't
control that or count on it.
8) When the servlet's doFoo() method is done sending output, it just
returns.
--
Steven J. Owens
[EMAIL PROTECTED]
"I'm going to make broad, sweeping generalizations and strong,
declarative statements, because otherwise I'll be here all night and
this document will be four times longer and much less fun to read.
Take it all with a grain of salt." - Me at http://darksleep.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
