tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <j...@kewlstuff.co.za>
Subject Re: Filters and getLastModified
Date Sun, 01 Jul 2007 13:13:33 GMT

----- Original Message ----- 
From: "Johnny Kewl" <john@kewlstuff.co.za>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Sunday, July 01, 2007 11:22 AM
Subject: Re: Filters and getLastModified


>
> You know LightBulb, been seeing your questions for a while now, you 
> clearly learning, but you have got one serious conceptual mind on you, not 
> enough just to use TC, hey ;).... I think its great, a guru in the making.
>
> To try answer your question, if its HTTP, the getLastModified() that you 
> provide in your servlet will be used. Naturally you could just set the 
> headers directly yourself as well. When you provide that overridden 
> method, its called by the servlet container, and all that really does is 
> set the headers for you.
>
> Theres a thing in TC called a Default-Servlet.... and this typically 
> serves up JSP pages.... it can already do this, and in fact does it for 
> you.
> So typically in a MVC model.... a request comes into your servlet, and if 
> you just using that servlet to "dispatch" it off to the correct JSP page, 
> then you dont need to worry, because the JSP will be served by the default 
> servlet, and the Last-Modified headers will be done automatically for you.

LIGHTBULB.... before I confuse the hell out of you.... in the above 
paragraph, meant the say HTML page.... not JSP page.
JSP.... is naturally also a servlet, once compiled, so same applies to 
that... Default Servlet does static pages, and thus the file attributes come 
into play.
Sorry rushing before shops closed.... also just the way I think about it in 
the MVC model, JSP pages are just used for display of results, they tend to 
become micky mouse things, with all the work done in the servlet.... I 
forget that some people put all their logic in the things.

>
> Filters should not affect the outcome unless off course its a CACHING 
> filter in which case you need to undersstand what its doing and just how 
> its playing with the Last-Modified and cache headers that are coming in. 
> So for example if the filter looks at a If-Modified-Since header from the 
> browser, and decides its not going to bother your servlet, and just return 
> it from a cache, your servlet will never see that request.
>
> In general if you have got a servlet that always serves new data, then you 
> dont bother with this stuff, and you just need to return the data, ie its 
> always fresh.
> Where it starts to get interesting is when people store images in a dB.... 
> then they lose those attributes that one normally has associated with a 
> file system, and if it is part of a feed, they got to do extra stuff, like 
> add another field to the dB to monitor if the image has changed, and then 
> that getLastModified() facility is going to come in very handy, so yes you 
> need to think about this stuff because just thinking that a dB is a cool 
> place to stick images, also opens up a whole efficiency issue.
>
> I'm no expert at this, but conceptually ;) there are two main area's of 
> caching.... the old HTTP spec which just deals with a browser cache, ie 
> typically it says, if the image is no older than say 30 mins, dont get it 
> again from the server.... thus helping servers cope, then there is the 
> newer stuff that allows for things like RSS feeds.
> These things depend very much on these If-Modified-Since headers, and 
> basically they poll the server, and for the server not to fall over, it 
> relys very much on these headers and the proper implementation of 
> getLastModified() to function correctly.
>
> Anyway, best advice I can give you is to search for HTTP CACHE HEADERS, on 
> google, and those articles will shed new light on why TC provides these 
> facilities, and just when and how to use them.
>
> In any normal browser you will see traditional caching at work, but if you 
> have IE 7, you can also play with RSS feeds, and get a feel for how this 
> all fits together.
>
> Great Question.... again ;)
>
> ----- Original Message ----- 
> From: "lightbulb432" <veerukrishnan@hotmail.com>
> To: <users@tomcat.apache.org>
> Sent: Sunday, July 01, 2007 3:19 AM
> Subject: Filters and getLastModified
>
>
>>
>> Could somebody explain when in the request process getLastModified is 
>> called
>> on a servlet? Is it before everything - all servlets, filters, listeners,
>> anything else?
>>
>> If you have multiple filters, how does this fit into the process - are 
>> they
>> all guaranteed to see the process through before the getLastModified call
>> occurs on the servlet? (i.e. Can you count on the filtering to have 
>> occurred
>> before the code in your getLastModified runs?)
>>
>> I ask in the case that your getLastModified is more than a simple file
>> system last modified timestamp check, and where you're using some kind of
>> controller servlet rather than servlet-per-path - in which case your one
>> getLastModified method in the controller servlet could become complex,
>> having to deal with multiple getLastModified semantics of multiple pages
>> that map to one servlet?
>>
>> With what request methods is it called (GET, POST, etc...)? The servlet 
>> spec
>> gives only a slight indication that it's for GETs, but doesn't really
>> elaborate.
>>
>> Thanks.
>> -- 
>> View this message in context: 
>> http://www.nabble.com/Filters-and-getLastModified-tf4006572.html#a11378442
>> Sent from the Tomcat - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> 


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


Mime
View raw message