I've just been looking back at what we were saying here... >>Of course, if you're not using sessions, there isn't the opportunity to do >>this. >Yes, you could do this, although considering the high level of binding >between getLM() and doGet(), this seems overkill to have to use the session >to communicate. I wouldn't consider the use of the session in this case >'easy' - although I'd be prepared to accept 'standard' ;-) I think I now fully understand this part of what you're saying.... eg: a fileservlet. getLM() probably has to create a new File object in order to inspect the Date of the file so that it can return it . When doGet is reached it has to go and get the file and thus create a new File object. Ok, I see some duplication here. But you have to remember 2 things: 1.this duiplication is not necessarily always occuring, considering the FileServlet again there may well be a cache and the cache would be updating the File in a thread somewhere else, so getLM would just ask the cache what the date of the File was; a much less intensive operation than creating the object 2. it is up to you the programmer to get round this, in the case described (the non-cache case) I would either make a cache with a thread to manage it, or if I didn't need that complexity use a request attribute to pass the File from getLM() to doGet(). RequestAttributes are an often ignored facility, but this is probably one of the reasons why they're in the spec. Anyway, this one reason isn't good enough IMHO, to make getLastModifed() extinct. Nic Ferrier ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
