[JBoss JIRA] Created: (GTNPORTAL-1750) Parameters in query string of include method call of RequestDispatcher not aggregating to JSP
by Rich Raposa (JIRA)
Parameters in query string of include method call of RequestDispatcher not aggregating to JSP
---------------------------------------------------------------------------------------------
Key: GTNPORTAL-1750
URL: https://issues.jboss.org/browse/GTNPORTAL-1750
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: QA
Affects Versions: 3.1.0-GA
Environment: JBoss EPP 5.1 GA
Reporter: Rich Raposa
Priority: Minor
Attachments: testportlet.zip
According to the spec (in section PLT.19.1.1): Parameters specified in the query string used to create the PortletRequestDispatcher must be aggregated with the portlet render parameters and take precedence over other portlet render parameters of the same name passed to the included servlet or JSP.
I have attached a really simple example that contains a query string parameter named "reply", but the renderRequest object in the included JSP does not contain any render request parameters. However, the parameter is in the HttpRequest object (which is fine, but it should also be a parameter of the renderRequest as well).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (GTNPC-49) Add methods on PortletInvoker that allow to whether a Portlet is exposed or known by the PortletInvoker without having to actually retrieve it
by Chris Laprun (JIRA)
Add methods on PortletInvoker that allow to whether a Portlet is exposed or known by the PortletInvoker without having to actually retrieve it
----------------------------------------------------------------------------------------------------------------------------------------------
Key: GTNPC-49
URL: https://issues.jboss.org/browse/GTNPC-49
Project: GateIn Portlet Container
Issue Type: Feature Request
Components: API
Affects Versions: 2.2.0-GA
Reporter: Chris Laprun
Assignee: Chris Laprun
Fix For: 2.3.0-GA
For example, the only way to know if a portlet (via its associated PortletContext) is an exposed one (e.g. a producer offered one) and not a customized version of an existing portlet (e.g. clone) is currently to retrieve the set of all portlets via getPortlets and iterate over them which is very inefficient speed and memory-wise (as it might result in the creation of structures discarded immediately after the operation).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months