DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40111>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40111





------- Additional Comments From [EMAIL PROTECTED]  2007-04-24 09:34 -------
According to the Servlet specification v2.4 (which Tomcat 5.5 implements) method
 HttpSession.getLastAccessedTime() should NOT throw any exceptions (even if
accessed on invalidated session).
Here is snapshot of the method description from the Servlet v2.4 API:
--------------------------------------------------
public long getLastAccessedTime()

    Returns the last time the client sent a request associated with this
session, as the number of milliseconds since midnight January 1, 1970 GMT, and
marked by the time the container received the request.

    Actions that your application takes, such as getting or setting a value
associated with the session, do not affect the access time.

    Returns:
        a long representing the last time the client sent a request associated
with this session, expressed in milliseconds since 1/1/1970 GMT
------------------------------------------------------

As you can see there is no 'Throws' section for the method description (like it
is for the HttpSession.getCreationTime() )


RESOLUTION:
This bug is caused by the
org.apache.catalina.session.StandardSession.getLastAccessedTime() method which
for version 5.5.23 currently throws IllegalStateException (but it should not):
-------------------------------------------------
/**
     * Return the last time the client sent a request associated with this
     * session, as the number of milliseconds since midnight, January 1, 1970
     * GMT.  Actions that your application takes, such as getting or setting
     * a value associated with the session, do not affect the access time.
     */
    public long getLastAccessedTime() {

        if ( !isValid() ) {
            throw new IllegalStateException
            (sm.getString("standardSession.getLastAccessedTime.ise"));
        }

        return (this.lastAccessedTime);
    }
-----------------------------------------------------

So I think Tomcat developers should FOLLOW the specification and FIX this bug.



Also for me it is strange why the getLastAccessedTime() method in the Servlet
v2.5 API (Tomcat 6.0.x) was changed to the throw IllegalStateException:
--------------------------------------------------------

long getLastAccessedTime()

    Returns the last time the client sent a request associated with this
session, as the number of milliseconds since midnight January 1, 1970 GMT, and
marked by the time the container received the request.

    Actions that your application takes, such as getting or setting a value
associated with the session, do not affect the access time.

    Returns:
        a long representing the last time the client sent a request associated
with this session, expressed in milliseconds since 1/1/1970 GMT 
    Throws:
        IllegalStateException - if this method is called on an invalidated 
session
------------------------------------------------------

API Spec Group have broken the way to determine if session is valid.
For example if my application contains the following code that calculates if the
session is valid:
----------
if (System.currentTimeMillis - sess.getLastAccessedTime() >
sess.getMaxInactiveInterval() * 1000) {
  ...
}
---------
it should correctly work in the containers that implement v2.3 and v2.4 Servlet
API. After migrating to v2.5 container the app will fail as it does not catches
the IllegalStateException.
And after all throwing exception is much expensive opration then math
calculation. Isn't it?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to