Gabriel Wong wrote: > "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. >From the Servlet 2.1a Spec: "A servlet context object is at least as unique as the host in which it resides. In a servlet engine that handles multiple virtual hosts (for example, by using the HTTP 1.1 host header), each virtual host must be treated as a separate context. Servlet engines can also provide context objects that are unique to a group of servlets. You can group servlets administratively or define them with a deployment descriptor. I wouldn't say there are no standards. I would just say that the standard allows for variability in the way ServletContexts are implemented. And it certainly appears that the spec leaves it wide open how context groups might be implemented in different engines. cc
begin:vcard n:Cobb;Christopher tel;cell:703-909-7550 tel;fax:703-648-7475 tel;work:703-648-6725 x-mozilla-html:TRUE org:Powerhouse Technologies, Inc. adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] title:SW Architect fn:Christopher Cobb end:vcard
