Gabriel Wong wrote:
>
> Although this makes a lot of sense since there are no standards for engine
> implementation I must point out:
As I pointed out, configuration of this stuff is currently servlet engine specific.
Future improvements in the servlet API are likely in this area.
>
> -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.
This is simply the degenerate case of mapping a single servlet context to the "/"
URI, so that an entire virtual host is in a single context. While such an
implementation may be minimally compliant with the spec (and is often the way that
2.0-compliant servlet engines were implemented), it won't be feature-competitive
with the engines that allow multiple contexts per virtual host. With JSP officially
"blessing" the concept that application == servlet context, market pressure to
provide this will be even stronger.
(Note that a single servlet context across multiple virtual hosts, even on the same
server, is *not* allowed.)
>
> -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.
>
On this one, there is no choice ... if session information created in one servlet
context (no matter how your servlet engine defines that) is visible in another
servlet context -- on the same virtual server or another -- then your servlet engine
is broken. It makes no difference what mapping approach you take, or how session
identifiers are communicated back and forth.
>
> Gabriel Wong
> http://www.ezwebtools.com
> ----------------------------
Craig McClanahan
===========================================================================
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".
