Craig,
Many thanks for your detailed answers, yes I do feel that I understand
the concept and use of the ServletContext a lot better now. I think you
have allayed my fears that the project we are currently designing was
going to require architectural hacks to deploy under JSP/Servlets. And
I now *get* URI's too....
It will be very interesting to see how (if ?) the JSP and Servlet teams
roadmap the future in the area of web application deployment at JavaOne.
I have scored a trip there all the way from Brisbane (if they can sort
out my &#^$*$ accomodation), so I will be the one sitting right up the
front taking notes # 8^-)
Thanks again, (and also to Gabriel and Christopher and the others who
contributed)
Drew Cox
Barrack Consulting
> -----Original Message-----
> From: Craig R. McClanahan [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, 14 May 1999 1:02
> To: Drew Cox
> Cc: [EMAIL PROTECTED]
> Subject: Re: Application scope
>
> (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".
