| Summary: | SetSupport.doEndTag overzealous about cleanup | ||
|---|---|---|---|
| Product: | Taglibs | Reporter: | Joe Germuska <Joe> |
| Component: | Standard Taglib | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 1.1.0 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | other | ||
Thanks for starting to investigate. IMO, line 118 of SetSupport.java has a bug, since it calls PageContext/JspContext#removeAttribute(String) instead of PageContext#remove(String,int), causing the "overzealousness" you refer to. You should see this behavior only if the value attribute of c:set evaluates to null. Is that consistent with what you are seeing? However, that's exactly what the JSTL 1.1 Spec. declares to be the correct
behavior. See "4.3 <c:set>" under the "Null & Error Handling" subsection.
Basically, if the value evaluates to null and no scope has been provided,
"...the scoped variable is removed according to the semantics of
PageContext.removeAttribute(varName)." So, for this case, the proper usage would be:
<c:set var="VENDOR" value="${sessionScope.BROWSE_VENDOR}" scope="page"/>
Kris, thanks for the research; I didn't go straight to the spec. Some documentation (like the O'Reilly JavaServer Pages book) describe the "default value" for "scope" as "page" -- I consider that inaccurate based on what you point out in the spec, but that's not a taglibs bug. I think it's incorrect to say that there is a default value for "scope", but rather that there is a well defined process for handling the absence of a "scope" value. Thanks a lot Kris! The line I mention is indeed immaculate with respect to the spec. As a side effect of this conversation, jstl spec public now has issue # 20. |
I'm not deeply familiar with the Standard taglibs code, but I have a reproducible problem. I had this tag in my code: <c:set var="VENDOR" value="${sessionScope.BROWSE_VENDOR}" /> and it was causing the "VENDOR" attribute to be cleared from the session. The naming is evolving, so that for now those two attribute names are intended to mean different things. I was puzzled about what was going on, but when I put in a SessionAttributeListener, I was able to determine that the behavior was instigated by: org.apache.jasper.runtime.PageContextImpl.removeAttribute(PageContextImpl.java:574) org.apache.taglibs.standard.tag.common.core.SetSupport.doEndTag(SetSupport.java:118) org.apache.jsp.catalog.Navigation_jsp._jspx_meth_c_set_1(Navigation_jsp.java:175) if I explicitly set VENDOR into page scope, then the session doesn't get touched. Or, if I use a different local name instead of VENDOR, the session doesn't get touched. I haven't quite figured out how this is working in the code, but these changes to the JSP seem to effectively control the behavior. (this is actually using standard-1.1.2.jar, but that version isn't in the versions...)