[jira] [Updated] (PLUTO-650) Objects such as portletConfig are available during JSP EL resolution even when portlet:defineObjects is not present
"Neil Griffin (JIRA)" <[email protected]>
| Newsgroups | gmane.comp.jakarta.pluto.devel |
|---|---|
| Message-ID | <[email protected]> |
[ https://issues.apache.org/jira/browse/PLUTO-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Neil Griffin updated PLUTO-650:
-------------------------------
Description:
The {{<portlet:defineObjects/>}} is a feature that enables the JSP pageContext to have attributes like {{portletConfig}}. One benefit of this feature is that JSP EL expressions can resolve these objects. For example:
{code:html}
<p>portletConfig=${portletConfig}</p>
{code}
If {{<portlet:defineObjects/>}} is missing from a JSP, then the objects should not appear as JSP pageContext attributes, and EL resolution should return {{null}}.
Pluto 3.0 contains a *regression* such that, even if {{<portlet:defineObjects/>}} is missing, EL resolution is returning a non-{{null}} value.
The cause of the regression is the presence of {{@Named}} on producer methods in PortletArtifactProducer.java which causes the WeldELResolver to invoke the producers during JSP EL resolution. The fix is to simply remove the {{@Named}} annotation from the producer methods.
h3. Steps to Reproduce:
- Deploy org.apache.portals.pluto.650.portlet.war (attached to this issue)
- Add the portlet to a Pluto portal page
- View the Pluto portal page
(/) Expected Result:
{noformat}
portletConfig=
renderRequest=
renderResponse=
portletSession=
portletSessionScope=
portletPreferences=
portletPreferencesValues=
portletRequest=
portletResponse=
renderParams=
portletContext=
portletMode=
windowState=
cookies=
locale=
locales=
namespace=
contextPath=
windowId=
portletName=
{noformat}
(x) Actual Result:
{noformat}
portletConfig=org.apache.pluto.driver.container.DriverPortletConfigImpl@8ff7529
renderRequest=org.apache.pluto.container.impl.RenderRequestImpl@f47cc70
renderResponse=org.apache.pluto.container.impl.RenderResponseImpl@32bed4e6
portletSession=org.apache.pluto.driver.services.container.CachedPortletSessionImpl@e8b6211
portletSessionScope={}
portletPreferences=org.apache.pluto.container.impl.PortletPreferencesImpl[]
portletPreferencesValues={}
portletRequest=org.apache.pluto.container.impl.RenderRequestImpl@f47cc70
portletResponse=org.apache.pluto.container.impl.RenderResponseImpl@32bed4e6
renderParams=org.apache.pluto.container.impl.RenderParametersImpl@60d3518c
portletContext=org.apache.pluto.driver.container.DriverPortletContextImpl@4e46cf03
portletMode=view
windowState=normal
cookies=[Ljavax.servlet.http.Cookie;@518eeffd
locale=en_US
locales=[Ljava.util.Locale;@7f2df4df
namespace=Pluto_org_apache_portals_pluto_650_portlet_1_1349732888_0_
contextPath=/org.apache.portals.pluto.650.portlet
windowId=org.apache.portals.pluto.650.portlet.1!1349732888|0
portletName=1
{noformat}
was:
The {{<portlet:defineObjects/>}} is a feature that enables the JSP pageContext to have attributes like {{portletConfig}}. One benefit of this feature is that JSP EL expressions can resolve these objects. For example:
{code:html}
<span>portletConfig=${portletConfig}</span>
{code}
If {{<portlet:defineObjects/>}} is missing from a JSP, then the objects should not appear as JSP pageContext attributes, and EL resolution should return {{null}}.
The JSR 378 TCK contains a test that expects the lack of {{<portlet:defineObjects/>}} to mean that the JSP pageContext attributes will not contain values like {{portletConfig}}.
Pluto 3.0 contains a *regression* such that, even if {{<portlet:defineObjects/>}} is missing, EL resolution is returning a non-{{null}} value.
h3. Steps to Reproduce:
- Create a portlet that contains the following JSP content:
{code:html}
<span>portletConfig=${portletConfig}</span>
{code}
- Deploy the portlet
- Add the portlet to a Pluto portal page
- View the Pluto portal page
(/) Expected Result:
{noformat}
portletConfig=
{noformat}
(x) Actual Result:
{noformat}
portletConfig=DriverPortletConfigImpl@8407
{noformat}
The reason why the value is found, even without the presence of {{<portlet:defineObjects/>}} is because the WeldELResolver is present in the JSP ELResolver chain and knows how to resolve the value.
> Objects such as portletConfig are available during JSP EL resolution even when portlet:defineObjects is not present
> -------------------------------------------------------------------------------------------------------------------
>
> Key: PLUTO-650
> URL: https://issues.apache.org/jira/browse/PLUTO-650
> Project: Pluto
> Issue Type: Bug
> Components: portlet container
> Affects Versions: 3.0.0
> Reporter: Neil Griffin
>
> The {{<portlet:defineObjects/>}} is a feature that enables the JSP pageContext to have attributes like {{portletConfig}}. One benefit of this feature is that JSP EL expressions can resolve these objects. For example:
> {code:html}
> <p>portletConfig=${portletConfig}</p>
> {code}
> If {{<portlet:defineObjects/>}} is missing from a JSP, then the objects should not appear as JSP pageContext attributes, and EL resolution should return {{null}}.
> Pluto 3.0 contains a *regression* such that, even if {{<portlet:defineObjects/>}} is missing, EL resolution is returning a non-{{null}} value.
> The cause of the regression is the presence of {{@Named}} on producer methods in PortletArtifactProducer.java which causes the WeldELResolver to invoke the producers during JSP EL resolution. The fix is to simply remove the {{@Named}} annotation from the producer methods.
> h3. Steps to Reproduce:
> - Deploy org.apache.portals.pluto.650.portlet.war (attached to this issue)
> - Add the portlet to a Pluto portal page
> - View the Pluto portal page
> (/) Expected Result:
> {noformat}
> portletConfig=
> renderRequest=
> renderResponse=
> portletSession=
> portletSessionScope=
> portletPreferences=
> portletPreferencesValues=
> portletRequest=
> portletResponse=
> renderParams=
> portletContext=
> portletMode=
> windowState=
> cookies=
> locale=
> locales=
> namespace=
> contextPath=
> windowId=
> portletName=
> {noformat}
> (x) Actual Result:
> {noformat}
> portletConfig=org.apache.pluto.driver.container.DriverPortletConfigImpl@8ff7529
> renderRequest=org.apache.pluto.container.impl.RenderRequestImpl@f47cc70
> renderResponse=org.apache.pluto.container.impl.RenderResponseImpl@32bed4e6
> portletSession=org.apache.pluto.driver.services.container.CachedPortletSessionImpl@e8b6211
> portletSessionScope={}
> portletPreferences=org.apache.pluto.container.impl.PortletPreferencesImpl[]
> portletPreferencesValues={}
> portletRequest=org.apache.pluto.container.impl.RenderRequestImpl@f47cc70
> portletResponse=org.apache.pluto.container.impl.RenderResponseImpl@32bed4e6
> renderParams=org.apache.pluto.container.impl.RenderParametersImpl@60d3518c
> portletContext=org.apache.pluto.driver.container.DriverPortletContextImpl@4e46cf03
> portletMode=view
> windowState=normal
> cookies=[Ljavax.servlet.http.Cookie;@518eeffd
> locale=en_US
> locales=[Ljava.util.Locale;@7f2df4df
> namespace=Pluto_org_apache_portals_pluto_650_portlet_1_1349732888_0_
> contextPath=/org.apache.portals.pluto.650.portlet
> windowId=org.apache.portals.pluto.650.portlet.1!1349732888|0
> portletName=1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)