[Drew Cox] Responses below (sorry about the quoting
mechanism... :-(
> > 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.
>
[Drew Cox] I'm not doubting that compiling to servlets are now
the official implementation of JSP with 1.0, this seems fair and
reasonable. It's just the line in the 0.92 spec - "JavaServer Pages are
compiled into objects, frequently Java Servlets, although we anticipate
third-party implementations using other object technologies". Evidently
this implementation independence is no longer a feature of the JSP
specification.
> 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.
>
[Drew Cox] Agreed. It is a step forward. I'm just not sure
they couldn't have taken two steps forward.....
>
> > 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.
>
[Drew Cox] I'm definitely operating out of my depth here, but
let me see if I understand what your saying. If I map
http://myServer/myApp to a servlet myApp.class and
http://myServer/yourApp to a servlet yourApp.class, do they both run in
the same ServletContext and thus share application scoped objects ?
Above, you seem to be saying no, they would be separate. If this is the
case, how do you build an "application" that is constructed from several
separate servlets ?
This is why I like the idea of an abstract concept of an
HttpApplication, similar to HttpSession, that would be available to both
Servlets and JSP beans/scripts to stash objects in. It just seems odd
to tie this directly to the ServletContext unnecessarily. It would also
enable something like HttpApplicationBindingListener, which would allow
objects stored in it to initialise and cleanup themselves. Could be
useful for the DB pooling classes being talked about in another thread ?
Maybe it's just the class naming that is throwing me ? There is
mention in the 2.1 spec of Deployment Descriptors that seem to
effectively group disparate servlets under a single context.
> 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.
>
[Drew Cox] Possible embarrassing newbie question. What *really*
is the difference between a URl and a URL ?
> >
> > 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.
>
[Drew Cox] Ahh, again, because the HttpSession is an
abstraction, not specifically tied to being stored in a collection on
the local VM, as is the usual implementation. It provides engine
writers room to manoeuvre.....
> >
> > Regards
> >
> > Drew Cox
> > Barrack Consulting
> >
>
> Craig McClanahan
>
[Drew Cox] Thanks for your input, Drew.
===========================================================================
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".
