Drew Cox wrote:
> Does anyone else think it's poor API design that the JSP spec defines
> the "application" scope directly in terms of the objects being stored in
> the ServletContext ?
>
> It seems very implementation dependant to me, in that it enforces the
> implementation of JSP where the page is compiled to a servlet, as well
> as forcing the ServletContext will be the container for application
> scoped objects. I'm sure I read somewhere in one of the earlier specs
> that JSP was designed to *not* be tied to a servlet based implementation
> ? Is that requirement out the window now ?
>
>From the JSP 1.0 draft specification, Section 1.2: "JavaServer Pages is a
Standard Extension that is defined on top of the Servlet Standard Extension."
It has been pretty clear all along that JSP pages would run in the servlet
engine envbironment -- what was de-emphasized in 1.0 was the assumption that
Java was the scripting language -- indeed, there are existing implementations
based on JavaScript and TCL.
Whether or not you think this is good, the specification statement that
application-scoped objects are stored in the ServletContext (and the
corresponding requirements for where session-scope and request-scope objects
go) filled a gigantic hole in the 0.92 spec, which was silent on where these
objects were to be found if you *were* running in a servlet-based world.
Servlet authors had no guarantee of consistency of how to communicate beans to
JSP pages without these mandates.
>
> I think it would be cleaner to create an abstract definition of an
> "application", defined in terms similar to that in ASP (no flames
> please). In that environment, all ASP pages under a nominated parent
> directory are considered part of the same "application". This defines
> an application in terms of the directory the source pages live in,
> rather than the runtime context they are executed in. I'm not sure how
> this concept would apply to pure servlets though, with their complex
> URL-to-servlet mapping schemes ?
>
In fact, a 2.1-based servlet environment will usually operate in exactly this
fashion -- a ServletContext will be attached to a particular URI prefix
(essentially equivalent to your "nominated parent directory" path), and all
URIs that begin with that prefix are handled by some servlet within that
context. The net effect is just as you describe ... informally, the scope of
an "application" is a particular directory prefix in the URI namespace of your
server.
The only extra "complexity" to URI-to-servlet mapping is that most servlet
engines offer you the ability to map a particular filename extension to a
particular servlet -- but in a 2.1 world that also happens inside a context
instead of globally (so you can even run a different JSP engine in your
context than I run in mine, for example) in a very clean and well-defined
manner.
>
> I imagine the above would also be more appropraite in the future
> load-balancing Servlet and JSP engines which may be spread across
> several VM's and physical machines. It's hard to imagine these sharing
> a single servlet context to implement a consistent application scope ?
>
Sharing application scope in a load balanced environment is definitely going
to be an issue for engine providers. However, several servlet engines today
already do this for session-scoped objects in a couple of different manners,
so it's clearly not impossible to contemplate.
>
> Regards
>
> Drew Cox
> Barrack Consulting
>
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
