Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of marc@marcchamberlin.com
 designates 206.58.200.12 as permitted sender)
MIME-Version: 1.0
Message-ID: <4C7FDA06.4010309@marcchamberlin.com>
Date: Thu, 02 Sep 2010 10:08:22 -0700
From: Marc Chamberlin <marc@marcchamberlin.com>
Reply-To: marc@marcchamberlin.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
 ThunderBrowse/3.3.1
To: users@tomcat.apache.org
Subject: Re: Question on SSI
References: <4C7EB3E0.8050200@marcchamberlin.com>
 <4C7EBC56.4030106@christopherschultz.net> <4C7ED919.70202@marcchamberlin.com>
 <4C7F0597.3080701@christopherschultz.net>
In-Reply-To: <4C7F0597.3080701@christopherschultz.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org