Since we've been discussing the 2.2 draft spec recently...
Some comments on 2.2 public review draft spec, in no particular order.
"In a distributed container, the default ServletContext is
non-distributable and must only exist on one VM"
As with 'normal' webapps, why not make this a deployment option/container
configuration parameter?
Is the ServletContext class allowed to be loaded by multiple class
loaders? The paragraph "...In cases where the servlet container is running
in a clustered or distributed configuration, there must only be one
instance of the ServletContext object per Application per Java Virtual
Machine..." If the Application is (re)loaded multiple times by the
container, must all instances share the same servlet context? I'm assuming
Application == Web Application.
Can WebApp archives contain generated jsp class files as well as jsp
pages?
Is it possible to use XML Schema rather than DTDs in the deployment
descriptor section of the spec for the next draft?
Is the scope of the load-on-startup integer in the deployment descriptor
web app or container? i.e. Does this integer specify what order the
container should load all servlets (on startup), or only how it should
load servlets within a web app (on startup)? Also is there a "don't care"
value, i.e. I want the servlet loaded on startup, but don't care about
ordering?
My assumption here when talking about load-on-startup is that startup ==
container startup. Is this correct?
Is there a WebApp life cycle, similar to that of the servlet?
Regarding error pages for WebApps, "exception-type", are there any
constraints on the exception type? e.g. subclass of Throwable? Does the
class need to be accessible from the container at WebApp load?
On the deployment descriptor, are there any plans to use namespaces to
qualify xml elements such as servlet or location? And rather than
'hard-coding' a deployment descriptor, how about allowing a servlet to
generate the xml 'on-demand', giving WebApps a well defined life cycle;
WEB-INF/webxml.class (or some variation) could be treated by the container
as the 'life cycle' of the web app. When loading a web app, the servlet is
loaded. The service method of this servlet is to produce a web.xml stream.
When the web app is to be removed from the container, the webxml serlvet's
destroy method is invoked.
Spelling mistake: principal and principle mixings.
ServletContext.getResource() and getResourceAsStream(): are these
resources to be restricted to within the associated web app, or can
resources be external to the web app?
META-INF under 1.2 can contain entries to externally required jar files,
rather than embedding the jar files within the archive as is the case in
the spec. Should these directives be honoured by the container? If not, is
there a plan to introduce this functionality into the WEB-INF directory?
Is there a reason other than backward compatibility that the HttpUtils
methods are not moved to HttpServletRequest, as all methods seem to deal
with request data manipulation?
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Play: http://www.trongus.com
___________________________________________________________________________
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
