> Few examples to be more explicit:
> - Someone is writing a servlet wich relies heavely on
>  PathInfo to perform actions  (not only on request parameters).
>  Thus we don't want such a servlet to be used within
>  any .type (file-extention) mapping, in wich getPathInfo() makes
>  no sense to this kind of servlets.

Sure it does... If a servlet is mapped to "/foo" the following play out:

        request "/foo/bar/bap"
        servletpath == "/foo"
        pathinfo == "/bar/bap"

        request "/foo/baz/bop"
        servletpath == "/foo"
        pathinfo == "/baz/bop"

        request "/foo/baz/bop/index.html"
        servletpath == "/foo"
        pathinfo == "/baz/bop/index.html"

Note that this last takes effect *even if* there is a
.html=someotherservlet mapping. This is why "directory" maps have
precendence over extension maps -- so that a servlet can take over a
path and get *all* requests into it.

>  Mabe some sort of  "INeedPathPrefixMapping",
>  "INeedTypeExtentionMapping"  empty interfaces will be usefull -
>   to let the servlet developer tell the servlet engine / deployer,
>   how *he* expects/want to be used.

I don't think we are going to go down this path -- yes there is some
amount of flexibility that would be there, but at the cost of *massive*
confusion and potential for problems. We'll be settling on one strategy
for doing servlet mappings so that it can be consistent.

> - The servlet developer's capability to deny
>   sub-path mapping to other servlets - to tell wich
>   servlets need to "be in charge" for their servlet-path
>   prefix, overriding any other longest-prefix-match sub-dir servlets..

Servlets are always peers -- one doesn't own another. This will always
be so. Now, there might be a call for an object that plugs in at the
"servletcontext" level that could map/unmap servlets, etc -- but that's
a whole nother thing.

> - Similar needs that a servlet might request
>   from its servlet-environment:
>   a. "I need a non-empty return from getRemoteUser()"
>       So the servlet-runner alerts the administrator, at installation
>       time to enable identification/authorisation for some servlets.
>
>   b. "I need access to local file system"  - so administrator is
>      aware of that and is able to deny or grant access to some specific
>     directories/files.

This sort of thing is not programmatic info -- but meta info that should
be carried in a deployment descriptor that can describe permissions,
security info, properties, etc -- and which can be modified at
deployment time. We are working on such a beast right now.

>  - developer should be able to group/deploy servlets within applications
>    (or other name, "package" is used)  instead of individual servlets.
>    Now, after installing few servlet-based "applications" adminitrators
>    lose the count on wich servlet belong to wich application, or
>    which the meaning of configuration parameters is.
>    How servlet-based applications are uninstalled?
>  - Means for some servlets to tell their envoironment
>    they require some specific configuration parameters.
>    e.g a mail servlet needs to know SMTP and POP/IMAP server addresses,
>    so the developer wants to tell the servlet engine what configuration
>    parameters should be requested from a local administrator.
>    (JWS's approach with bean servlets is interesting..)
>
>  - a servlet being able to say "I want to be loaded as soon as
>    engine starts" vs. let the administrators to do that.
>    (So we-ll be able to have a guaranteed initialisation/configuration
>     for a group of servlets, if a "first-started" servlet takes care of
>     all necessary configurations).

All of these are part of a deployment story that we'll be hammering out
for the next rev of the spec. (no, I don't have dates or a preliminary
copy ready for public review at this time).

.duncan

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to