You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "nik gonzalez (JIRA)" <pl...@jakarta.apache.org> on 2005/03/05 00:00:46 UTC
[jira] Created: (PLUTO-113) HttpServletRequest.getAttribute returns namespaced attribute names
HttpServletRequest.getAttribute returns namespaced attribute names
------------------------------------------------------------------
Key: PLUTO-113
URL: http://issues.apache.org/jira/browse/PLUTO-113
Project: Pluto
Type: Bug
Components: portlet container
Versions: 1.0.1-rc3
Reporter: nik gonzalez
If I set an attribute in the RenderRequest like so:
request.setAttribute("bob", entity);
I can (with one exception noted below) read it from the HttpServletRequest in an included JSP/jspTag, thusly:
Object test3 = pageContext.getRequest().getAttribute("bob");
However if I obtain an enumeration of the attribute names:
Enumeration attrNames = pageContext.getRequest().getAttributeNames();
I will see the attribute in a namespaced form. Ie:
"Pluto_1574_bob"
When obtaining the enumeration from the RenderRequest the names do not include this namespacing.
Note the Portlet spec, PLT.16.3.3 "Request and Response objects for Included Servlets/JSPs", on page 67 line 16, wherein it is proclaimed that the method getAttributeNames must be like unto its PortletRequest equivalant.
Additionally, use of the name "entity" for request attributes doesnt work. It appears the container is using it to remember part of the portlets namespace, and this will silently override any attempt to set a request attribute named "entity".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (PLUTO-113) HttpServletRequest.getAttribute returns namespaced attribute names
Posted by "Stefan Hepper (JIRA)" <pl...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-113?page=all ]
Stefan Hepper closed PLUTO-113:
-------------------------------
Fix Version: 1.0.1-rc3
Resolution: Cannot Reproduce
> HttpServletRequest.getAttribute returns namespaced attribute names
> ------------------------------------------------------------------
>
> Key: PLUTO-113
> URL: http://issues.apache.org/jira/browse/PLUTO-113
> Project: Pluto
> Type: Bug
> Components: portlet container
> Versions: 1.0.1-rc3
> Reporter: nik gonzalez
> Fix For: 1.0.1-rc3
>
> If I set an attribute in the RenderRequest like so:
> request.setAttribute("bob", entity);
> I can (with one exception noted below) read it from the HttpServletRequest in an included JSP/jspTag, thusly:
> Object test3 = pageContext.getRequest().getAttribute("bob");
> However if I obtain an enumeration of the attribute names:
> Enumeration attrNames = pageContext.getRequest().getAttributeNames();
> I will see the attribute in a namespaced form. Ie:
> "Pluto_1574_bob"
> When obtaining the enumeration from the RenderRequest the names do not include this namespacing.
> Note the Portlet spec, PLT.16.3.3 "Request and Response objects for Included Servlets/JSPs", on page 67 line 16, wherein it is proclaimed that the method getAttributeNames must be like unto its PortletRequest equivalant.
> Additionally, use of the name "entity" for request attributes doesnt work. It appears the container is using it to remember part of the portlets namespace, and this will silently override any attempt to set a request attribute named "entity".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (PLUTO-113) HttpServletRequest.getAttribute returns namespaced attribute names
Posted by "Stefan Hepper (JIRA)" <pl...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-113?page=comments#action_12312481 ]
Stefan Hepper commented on PLUTO-113:
-------------------------------------
I was not able to verify this on the current 1.0.1-rc3 and tomcat 5.0. It correctly returned the attribute without any namespace:
(I used the attribute "mytest" with "myvalue" as value):
portlet output:
Namespaced attribute test
Get attribute directly from the page context: myValue
Get all attribute names from the page context: attrname = myName
> HttpServletRequest.getAttribute returns namespaced attribute names
> ------------------------------------------------------------------
>
> Key: PLUTO-113
> URL: http://issues.apache.org/jira/browse/PLUTO-113
> Project: Pluto
> Type: Bug
> Components: portlet container
> Versions: 1.0.1-rc3
> Reporter: nik gonzalez
>
> If I set an attribute in the RenderRequest like so:
> request.setAttribute("bob", entity);
> I can (with one exception noted below) read it from the HttpServletRequest in an included JSP/jspTag, thusly:
> Object test3 = pageContext.getRequest().getAttribute("bob");
> However if I obtain an enumeration of the attribute names:
> Enumeration attrNames = pageContext.getRequest().getAttributeNames();
> I will see the attribute in a namespaced form. Ie:
> "Pluto_1574_bob"
> When obtaining the enumeration from the RenderRequest the names do not include this namespacing.
> Note the Portlet spec, PLT.16.3.3 "Request and Response objects for Included Servlets/JSPs", on page 67 line 16, wherein it is proclaimed that the method getAttributeNames must be like unto its PortletRequest equivalant.
> Additionally, use of the name "entity" for request attributes doesnt work. It appears the container is using it to remember part of the portlets namespace, and this will silently override any attempt to set a request attribute named "entity".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira