> 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