On 9/1/2010 7:01 PM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marc,
On 9/1/2010 6:52 PM, Marc Chamberlin wrote:
On 9/1/2010 1:49 PM, Christopher Schultz wrote:
You will have to use filter mapping in order to post-process your .jsp
and other dynamic pages: a servlet can't be wrapped around another
servlet (such as the JSPServlet, which you don't have to map yourself)
for this kind of thing. So, stick with the filter.
OK, I kinda gathered that a filter is applied to everything served up by
the server, before servlets are invoked... So it makes sense that a
filter has to be used (if I am understanding this correctly) for JSP
Servlets....
Technically speaking, the filter "wraps" the call to the actual servlet
(or, even, other filters that get called before the servlet). They can
act either before or after the servlet, or both. The SSI filter wraps
the request handed-off to the "filter chain" (which ultimately ends by
calling a servlet) and buffers the response. After the rest of the
filter chain has run (and presumably produced output), the SSI filter
completes its task by actually running that buffered-output through the
SSI processor to actually *do* all of the SSI stuff. The result is then
sent to the client.
Honestly, I'm not sure why the SSI Servlet is even included: the
DefaultServlet handles files on the disk, etc. quite nicely and the SSI
Filter can be used to filter them, too. See my related post on the SSI
Filter implementation if you're interested.
Aww THANKS for the explanation Christopher! That helps a lot... And I
think I follow you on the SSI Servlet, I was unsuccessful in getting SSI
to work with it, and have not gone back and retried... The Filter
approach seems more intuitive to me..
Note that you should be able to set up SSI in a single webapp instead of
modifying the conf/web.xml file as described in the SSI documentation. I
find this cleaner, as you will only end up making SSI available in a
specific webapp instead of across all webapps deployed onto the server.
The<filter-mapping> itself should definitely only be included in your
webapp's META-INF/web.xml file.
Not sure I fully understand you here, so please forgive my lack of
understanding... I do want this SSI feature to be available across all
the webapps deployed on our server. As I mentioned previously, we want
to provide some services that users can access, by simply including a
server side include statement that will effectively include these
features on their web pages.
Gotcha. Feel free to enable this site-wide, then (using conf/web.xml).
Evidently, you'll also have to make all contexts that want to use SSI
"privileged". I'm not entirely sure that's true if you enable it at the
top-level as you are doing. Please let us know.
I changed to Context tag declaration in the Context.xml file to
<Context privileged="true"> and that enables SSI for all my webapps (so
far as I have tested it)
Again thanks for your time and help! A little bit of the fog has lifted
for me! ;-) Marc...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
