(I'm doing some major snipping to address several of Drew's questions)
Drew Cox wrote:
> [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 ?
>
It's actually a two-level mapping, instead of one-level. The details of how
you set this up are different for each servlet engine, but the concepts are
the same. Let's say we have the following applications running on the same
server: a catalog where you can buy some CDs, and another app that is a
search engine. You could set it up like this:
* Context #1 mapped to "/catalog"
* Servlet #1 (CatalogBrowseServlet) mapped to "/browse"
so that it's entire URI is "/catalog/browse"
* Servlet #2 (CheckoutServlet) mapped to "/checkout"
so that it's entire URI is "/catalog/checkout"
* A mapping of the ".jsp" extension to GNUJSP
for handling JavaServer Pages invocations
within this context
* Application-scoped objects are shared only
between the catalog-related servlets and
JSP pages.
* Context #2 mapped to "/search"
* Servlet #1 (RequestServlet) mapped to "/browse"
so that it's entire URI is "/search/browse"
(and thus distinct from CatalogBrowseServlet).
* Servlet #2 (ResultsServlet) mapped to "/results"
so that it's entire URI is "/search/results"
* A mapping of the ".jsp" extension to some other
JavaServer Pages implementation because the
author of the search app did not know about
GNUJSP.
* Application-scoped objects are shared only
between the search-related servlets and
JSP pages.
What happens under the covers is that the web server first decides which
context should handle a particular request, by matching on the initial part of
the URI (/catalog or /search in this example). Then, the context itself
decides which servlet should handle the request, based on either matching a
mapping (/catalog/browse is handled by CatalogBrowseServlet) or by extension
mapping (/catalog/index.jsp is handled by the GNUJSP servlet).
One other thing to remember -- sessions are also specific to a context, so a
user session in one application will never see session data created by the
other application, and vice versa.
>
> 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 ?
>
>From the JSP page author's point of view, it is not visible that a
ServletContext is being used underneath -- they just refer to the
"application" object. If you do all your programming in JSP pages, then it's
transparent to you. If you are doing any non-JSP programming (servlets), you
need a specified way to communicate objects between your servlets and the JSP
pages to guarantee consistency across JSP implementations.
You're absolutely right about needing something like
HttpApplicationBindingListener. There's been lots of discussion about this
among the servlet API experts, and you'll probably see something in the next
API rev -- along with (I hope) movements towards an "application deployment"
scheme that lets you package up a bunch of servlets, JSP pages, static HTML
pages, image files, and other resources into a single deployable "thing" that
you can plop down into any conforming servlet engine environment -- and attach
to any URI prefix (see below for the answer to this :-) -- without changing
the app at all.
For example, lets say the webmaster in my scenario above wanted to connect the
catalog to "/store" instead of "/catalog". Under the current specs, you have
to be really careful in how you code your links to make this easy -- with a
deployment descriptor approach of some sort, you'd change one parameter and
everything else would adjust auto-magically, because internal references would
be considered local to the context, instead of global to the web server.
> 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.
>
But even without a deployment descriptor, 2.1-compliant servlet engines let
you do this ... it's just engine-specific how it is configured.
>
> > 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 ?
Consider the URL:
http://www.mycompany.com:8080/catalog/browse?category=Jazz
Then the URI portion is the part that's after the host+port, and before the
query parameters, i.e.
/catalog/browse
and this is what is returned by the request.getRequestURI() method. Lots of
people use the terms interchangeably, but they really are different.
>
> > >
> > > 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.....
>
Well, a ServletContext is an abstraction as well (it's defined as a Java
interface that has to be implemented by some object in the servlet engine) --
the spec does not mandate that either or both support a distributed
environment; they just declare what the semantics should be if you do so.
>
> > >
> > > Regards
> > >
> > > Drew Cox
> > > Barrack Consulting
> > >
> >
> > Craig McClanahan
> >
> [Drew Cox] Thanks for your input, Drew.
>
Good questions ... and I hope my explanations made things a little clearer :-)
Craig
===========================================================================
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".
