Remy Maucherat wrote:
> Bill Barker wrote:
> 
>>----- Original Message ----- From: "Remy Maucherat" <[EMAIL PROTECTED]>
>>To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
>>Sent: Tuesday, March 22, 2005 1:57 AM
>>Subject: Re: cvs commit: 
>>jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session 
>>StandardSession.java
>>
>>
>>
>>>[EMAIL PROTECTED] wrote:
>>>
>>>
>>>>billbarker    2005/03/21 19:50:03
>>>>
>>>>  Modified:    catalina/src/share/org/apache/catalina/session
>>>>                        StandardSession.java
>>>>  Log:
>>>>  From the comments for R1.11, it seems that some early version of 
>>>>the spec had an exception here.  However, this didn't survive to the 
>>>>final spec version, so we can once again allow access to 
>>>>getLastAccessedTime from an invalid session.
>>>>  Fix for Bug #34107
>>>
>>>
>>>I didn't know that, as the javadoc actually says:
>>>
>>>getLastAccessedTime
>>>
>>>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
>>>    Throws:
>>>
>>>>>>       java.lang.IllegalStateException - if this method is called
>>>
>>>on an invalidated session
>>>
>>>Which paragraph in the spec has the conflicting statement ?
>>>
>>
>>It's the java-doc for jakarta-servletapi-5 that is wrong.  The javadocs 
>>in the servlet spec do not contain a 'throws' clause.  See also: 
>>http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpSession.html#getLastAccessedTime()
>> 
> 
> 
> Here: 
> http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/154errata.txt
> 
> I now read:
> 2. Fix typos in HttpSession.java
> 
>     Replace:
> 
>       * @exeption IllegalStateException if this method is called on an
>       *                                 invalidated session
> 
>     in javadoc of getId() and getLastAccessedTime()
>     With:
> 
>       * @exception IllegalStateException if this method is called on an
>       *                                  invalidated session
> 
>     This fix causes the following addition to HttpSession.getId() and
>     HttpSession.getLastAccessedTime() methods. Since these two methods are
>     already implemented in all containers to throw this exception and the
>     spec clearly intends to do so, this is not changing the spec.
> 
>     SRV.15.1.7.1 Page 267, 268
> 
>       Throws:
>       IllegalStateException - if this method is called on an invalidated
>                               session
> 
> There's highly conflicting information ...


I think the intention is for both methods to throw an ISE in case
they're being called on an invalidated session, as has been clarified
by the errata.

It seems this has been the intent for both methods from the very
beginning, except that the throws clauses in the javadocs at
  http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpSession.html

which are also copied in the servlet spec, were never generated for
these 2 methods because of a stupid typo (@exeption vs @exception) in
the HttpSession.java source file.

The HttpSession.java source in jakarta-servletapi-5 already has the fix.

My believe is that the above errata will be reflected in the next
(maintenance) release of the servlet spec. I will remind the servlet
spec lead that this needs to happen.


Jan






> Rémy
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

Reply via email to