> /*** There are actually two options for controlling HTML access, and the
> key is whether the "file serving servlet" has been configured for the web
> application containing that the HTML page. If the containing web
> application does not have the file serving servlet configured, then the
> HTTP webserver is charge of serving the HTML page. If the file serving
> servlet is configured, then the HTTP webserver's plugin code will send the
> http request to the WebSphere's servlet engine, which in turn will locate
> the HTML page and return it back to the HTTP webserver. WebSphere
> "default" web application does not have the file serving servlet
> configured, so I am suspecting it was this web application that you have
> been working with. When the file serving servlet is configured, then the
> HTML pages must be placed alongside the JSPs in the web app's document
> root. (Only one document root is allowed per web app.) I think the
> primary tradeoff here is speed vs. organization: it is better
> performancewise to have the HTTP webserver serve static HTML than to send
> the request to an out-of-process servlet engine. But if you have a bunch
> of web app's, you can organize your HTML files into each web
> app's document
> root - it is better for your sanity.
> ***/
I've looked all over the adminconsole, and I don't see where I can configure
a file serving servlet. Not only that, I'm not sure I understand how an
HTML page is "contained" in an application. When an HTTP request for a URL
comes in on a given port, who determines that requests on that port are
supposed to go to a file serving servlet, and which one?
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---
