tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java
Date Tue, 27 May 2003 08:15:22 GMT

----- Original Message -----
From: "Remy Maucherat" <remm@apache.org>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sent: Monday, May 26, 2003 11:29 PM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core
ApplicationHttpRequest.java


> Bill Barker wrote:
> >>remm        2003/05/26 05:02:31
> >>
> > This spec is a bit fuzzy on this, but I actually rather liked the
previous
> > behavior where you can't pass Request attributes back to the calling
page.
> > Without clarification from the spec team, I'm -0 on this.
>
> Actually, it's more complex than that. The old code was:
>
>      public void setAttribute(String name, Object value) {
>
>          synchronized (attributes) {
>              attributes.put(name, value);
>              if (!isSpecial(name))
>                  getRequest().setAttribute(name, value);
>          }
>
>      }
>
> Similarly:
>
>      public void removeAttribute(String name) {
>
>          synchronized (attributes) {
>              attributes.remove(name);
>              if (!isSpecial(name))
>                  getRequest().removeAttribute(name);
>          }
>
>      }
>
> (Note: why syncing ????)
>

I have no complaint with removing the syncs.  Catalina tends to overdo them
any way :).

> getAttribute also accesses the wrapped request if the local collection
> doesn't contain the requested attribute, and the attribute isn't a
> request dispatcher attribute.
>
> So unless the attribute is request dispatcher related, the wrapped
> request is mutated. Additionally, the spec says nothing about isolating
> request atributes, so that means that it can be used to pass around
> request state information (and rightfully so, using request parameters
> is inefficient and one way only; otherwise, the last resort would be the
> session).

Isolating the request attributes is the feature I liked.  Granted that the
spec is fuzzy, which is why I stuck to -0.  The change is for e.g:

public class A extends HttpServlet {
   public void doGet(HttpServletRequest request, HttpServletResponse
response)
      throws ServletException,IOException {
         response.setContentType("text/html; charset=iso-latin-1");
         PrintWriter out = response.getWriter();
        out.println("<html><head></head><body>");
         request.setAttribute("foo","bar");
         RequestDispatcher rd = getServletContext().getNamedDispatcher("B");
         rd.include(request, response);
         out.println("<h2>" +request.getAttribute("foo") + "</h2>");
         out.println("</body></html>")
    }
}
public class B extends HttpServlet {
   public void doGet(HttpServletRequest request, HttpServletResponse
response)
       throws ServletException, IOExeption {
          request.setAttribute("foo","foobar");
        }
}

This is very different now between 4.1.x and 5.0.x (the first prints "bar",
and the second prints "foobar").  I, personally, prefer the 4.1.x behavoir.



>
> So what was the point duplicating the attributes, and also maintaining a
> complete separate attributes collection ?
>
> The new code isolates the request dispatcher attributes, but relies on
> the wrapped request for all other attributes. I think this is completely
> equivalent to the old code (but more efficient since there's only one
> collection).
>
> The specification doesn't actually require the request to be wrapped
> (unless wrapping occurred in the user code). Attributes handling doesn't
> actually require wrapping; the only real problem is for parameters
> handling (but we could add specialized code to do that in CoyoteRequest).
>
> Note: I have always been slightly confused by the Catalina
> implementation of the request dispatcher; hopefully, I spent enough time
> reviewing it :)
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message