"Craig R. McClanahan" wrote:
> (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.
Although this makes a lot of sense since there are no standards for engine
implementation I must point out:
-According to the Context API the minimal context mapping is the host. So an
engine may or may not map the Context to the URI.
-For sessions being tied to a specific context (one mapped to a URI) a Cookie
based session would definitely work but the same may not apply for a URL encoded
session because the engine may associate a given session with any URI.
Gabriel Wong
http://www.ezwebtools.com
----------------------------
===========================================================================
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".
