tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Question on SSI
Date Thu, 02 Sep 2010 02:01:59 GMT
-----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.

>> 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.

> And like I mentioned, I have gotten this
> working in one sense, but the include statement only works for me from
> within .shtml files and I need it to work from within .html, .htm, and
> .jsp files.

It looks like you've gotten this working the correct combination of
url-pattern and contentType configuration.

Good luck in the future,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx/BZcACgkQ9CaO5/Lv0PDI7QCeJIghAxNYbqNiwmcIQzZ01ppT
4ooAoIRD7mRVmUJjTRCjrIYsU84VcU9w
=omY5
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message