You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Kito D. Mann (JIRA)" <de...@myfaces.apache.org> on 2007/12/10 08:21:43 UTC
[jira] Created: (PORTLETBRIDGE-20) PortletConfig not added to the
proper ELContext
PortletConfig not added to the proper ELContext
-----------------------------------------------
Key: PORTLETBRIDGE-20
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-20
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Environment: Windows XP, eXo WebOS 2.0, snapshot as of 12/8, Tomcat 6
Reporter: Kito D. Mann
Currently, the "porletConfig" implicit variable consistently evaluates to null. After stepping through the code, it looks as if BridgeImpl is adding the PortletConfig object to the wrong ELContext.
BridgeImpl adds itself as an ELContext listener:
// Add self as ELContextListener to the Faces App so we can add the
// portletConfig to any newly created contexts.
ApplicationFactory appFactory =
(ApplicationFactory) FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
Application app = appFactory.getApplication();
app.addELContextListener(this);
so that the following method gets called when a new ELContext is created:
public void contextCreated(ELContextEvent ece)
{
// Add the portletConfig to the ELContext so it is evaluated
ELContext elContext = ece.getELContext();
// Only add if not already there
if (elContext.getContext(PortletConfig.class) == null)
{
elContext.putContext(PortletConfig.class, mPortletConfig);
}
}
However, it looks like this method is called by the JSP container (in Tomcat, this is called by JspApplicationContextImpl.createELContext()). So, the ELContext implementation passed in is the JSP container's ELContext, as opposed to the one created by PortletFacesContext. So, when the PorltetELResolver executes the following code in its getValue() method:
case PORTLET_CONFIG:
context.setPropertyResolved(true);
return context.getContext(PortletConfig.class);
It actually returns null, because it's checking the wrong context instance (in this case, it's checking the PortletELContext, as expected).
I'm not sure if this is the expected behavior of the container, but it would explain by why the RI's FacesContextImpl doesn't call ELContextListeners directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PORTLETBRIDGE-20) PortletConfig not added to the
proper ELContext
Posted by "Kito D. Mann (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552149 ]
Kito D. Mann commented on PORTLETBRIDGE-20:
-------------------------------------------
FWIW, I just applied the patch locally and it appears to solve the issue for me.
> PortletConfig not added to the proper ELContext
> -----------------------------------------------
>
> Key: PORTLETBRIDGE-20
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-20
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 1.0.0-SNAPSHOT
> Environment: Windows XP, eXo WebOS 2.0, snapshot as of 12/8, Tomcat 6
> Reporter: Kito D. Mann
> Attachments: jira_20.patch
>
>
> Currently, the "portletConfig" implicit variable consistently evaluates to null. After stepping through the code, it looks as if BridgeImpl is adding the PortletConfig object to the wrong ELContext.
> BridgeImpl adds itself as an ELContext listener:
> // Add self as ELContextListener to the Faces App so we can add the
> // portletConfig to any newly created contexts.
> ApplicationFactory appFactory =
> (ApplicationFactory) FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
> Application app = appFactory.getApplication();
> app.addELContextListener(this);
> so that the following method gets called when a new ELContext is created:
> public void contextCreated(ELContextEvent ece)
> {
> // Add the portletConfig to the ELContext so it is evaluated
> ELContext elContext = ece.getELContext();
> // Only add if not already there
> if (elContext.getContext(PortletConfig.class) == null)
> {
> elContext.putContext(PortletConfig.class, mPortletConfig);
> }
> }
> However, it looks like this method is called by the JSP container (in Tomcat, this is called by JspApplicationContextImpl.createELContext()). So, the ELContext implementation passed in is the JSP container's ELContext, as opposed to the one created by PortletFacesContext. So, when the PorltetELResolver executes the following code in its getValue() method:
> case PORTLET_CONFIG:
> context.setPropertyResolved(true);
> return context.getContext(PortletConfig.class);
> It actually returns null, because it's checking the wrong context instance (in this case, it's checking the PortletELContext, as expected).
> I'm not sure if this is the expected behavior of the container, but it would explain by why the RI's FacesContextImpl doesn't call ELContextListeners directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (PORTLETBRIDGE-20) PortletConfig not added to the
proper ELContext
Posted by "Michael Freedman (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Freedman updated PORTLETBRIDGE-20:
------------------------------------------
Status: Patch Available (was: Open)
> PortletConfig not added to the proper ELContext
> -----------------------------------------------
>
> Key: PORTLETBRIDGE-20
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-20
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 1.0.0-SNAPSHOT
> Environment: Windows XP, eXo WebOS 2.0, snapshot as of 12/8, Tomcat 6
> Reporter: Kito D. Mann
>
> Currently, the "portletConfig" implicit variable consistently evaluates to null. After stepping through the code, it looks as if BridgeImpl is adding the PortletConfig object to the wrong ELContext.
> BridgeImpl adds itself as an ELContext listener:
> // Add self as ELContextListener to the Faces App so we can add the
> // portletConfig to any newly created contexts.
> ApplicationFactory appFactory =
> (ApplicationFactory) FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
> Application app = appFactory.getApplication();
> app.addELContextListener(this);
> so that the following method gets called when a new ELContext is created:
> public void contextCreated(ELContextEvent ece)
> {
> // Add the portletConfig to the ELContext so it is evaluated
> ELContext elContext = ece.getELContext();
> // Only add if not already there
> if (elContext.getContext(PortletConfig.class) == null)
> {
> elContext.putContext(PortletConfig.class, mPortletConfig);
> }
> }
> However, it looks like this method is called by the JSP container (in Tomcat, this is called by JspApplicationContextImpl.createELContext()). So, the ELContext implementation passed in is the JSP container's ELContext, as opposed to the one created by PortletFacesContext. So, when the PorltetELResolver executes the following code in its getValue() method:
> case PORTLET_CONFIG:
> context.setPropertyResolved(true);
> return context.getContext(PortletConfig.class);
> It actually returns null, because it's checking the wrong context instance (in this case, it's checking the PortletELContext, as expected).
> I'm not sure if this is the expected behavior of the container, but it would explain by why the RI's FacesContextImpl doesn't call ELContextListeners directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PORTLETBRIDGE-20) PortletConfig not added to the
proper ELContext
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552473 ]
Scott O'Bryan commented on PORTLETBRIDGE-20:
--------------------------------------------
Cool Kito, thanks for testing. If not already done so I'll apply the patch today.
> PortletConfig not added to the proper ELContext
> -----------------------------------------------
>
> Key: PORTLETBRIDGE-20
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-20
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 1.0.0-SNAPSHOT
> Environment: Windows XP, eXo WebOS 2.0, snapshot as of 12/8, Tomcat 6
> Reporter: Kito D. Mann
> Attachments: jira_20.patch
>
>
> Currently, the "portletConfig" implicit variable consistently evaluates to null. After stepping through the code, it looks as if BridgeImpl is adding the PortletConfig object to the wrong ELContext.
> BridgeImpl adds itself as an ELContext listener:
> // Add self as ELContextListener to the Faces App so we can add the
> // portletConfig to any newly created contexts.
> ApplicationFactory appFactory =
> (ApplicationFactory) FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
> Application app = appFactory.getApplication();
> app.addELContextListener(this);
> so that the following method gets called when a new ELContext is created:
> public void contextCreated(ELContextEvent ece)
> {
> // Add the portletConfig to the ELContext so it is evaluated
> ELContext elContext = ece.getELContext();
> // Only add if not already there
> if (elContext.getContext(PortletConfig.class) == null)
> {
> elContext.putContext(PortletConfig.class, mPortletConfig);
> }
> }
> However, it looks like this method is called by the JSP container (in Tomcat, this is called by JspApplicationContextImpl.createELContext()). So, the ELContext implementation passed in is the JSP container's ELContext, as opposed to the one created by PortletFacesContext. So, when the PorltetELResolver executes the following code in its getValue() method:
> case PORTLET_CONFIG:
> context.setPropertyResolved(true);
> return context.getContext(PortletConfig.class);
> It actually returns null, because it's checking the wrong context instance (in this case, it's checking the PortletELContext, as expected).
> I'm not sure if this is the expected behavior of the container, but it would explain by why the RI's FacesContextImpl doesn't call ELContextListeners directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-20) PortletConfig not added to the
proper ELContext
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott O'Bryan resolved PORTLETBRIDGE-20.
----------------------------------------
Resolution: Fixed
Thanks to Michael Freedman for the patch!
Committed r605725.
> PortletConfig not added to the proper ELContext
> -----------------------------------------------
>
> Key: PORTLETBRIDGE-20
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-20
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 1.0.0-SNAPSHOT
> Environment: Windows XP, eXo WebOS 2.0, snapshot as of 12/8, Tomcat 6
> Reporter: Kito D. Mann
> Assignee: Scott O'Bryan
> Attachments: jira_20.patch
>
>
> Currently, the "portletConfig" implicit variable consistently evaluates to null. After stepping through the code, it looks as if BridgeImpl is adding the PortletConfig object to the wrong ELContext.
> BridgeImpl adds itself as an ELContext listener:
> // Add self as ELContextListener to the Faces App so we can add the
> // portletConfig to any newly created contexts.
> ApplicationFactory appFactory =
> (ApplicationFactory) FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
> Application app = appFactory.getApplication();
> app.addELContextListener(this);
> so that the following method gets called when a new ELContext is created:
> public void contextCreated(ELContextEvent ece)
> {
> // Add the portletConfig to the ELContext so it is evaluated
> ELContext elContext = ece.getELContext();
> // Only add if not already there
> if (elContext.getContext(PortletConfig.class) == null)
> {
> elContext.putContext(PortletConfig.class, mPortletConfig);
> }
> }
> However, it looks like this method is called by the JSP container (in Tomcat, this is called by JspApplicationContextImpl.createELContext()). So, the ELContext implementation passed in is the JSP container's ELContext, as opposed to the one created by PortletFacesContext. So, when the PorltetELResolver executes the following code in its getValue() method:
> case PORTLET_CONFIG:
> context.setPropertyResolved(true);
> return context.getContext(PortletConfig.class);
> It actually returns null, because it's checking the wrong context instance (in this case, it's checking the PortletELContext, as expected).
> I'm not sure if this is the expected behavior of the container, but it would explain by why the RI's FacesContextImpl doesn't call ELContextListeners directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PORTLETBRIDGE-20) PortletConfig not added to the
proper ELContext
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553519 ]
Scott O'Bryan commented on PORTLETBRIDGE-20:
--------------------------------------------
I'm going to modify this patch to use the JDK 1.5 foreach notation. It's a wash on performance and is a bit clearer to read.
> PortletConfig not added to the proper ELContext
> -----------------------------------------------
>
> Key: PORTLETBRIDGE-20
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-20
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 1.0.0-SNAPSHOT
> Environment: Windows XP, eXo WebOS 2.0, snapshot as of 12/8, Tomcat 6
> Reporter: Kito D. Mann
> Assignee: Scott O'Bryan
> Attachments: jira_20.patch
>
>
> Currently, the "portletConfig" implicit variable consistently evaluates to null. After stepping through the code, it looks as if BridgeImpl is adding the PortletConfig object to the wrong ELContext.
> BridgeImpl adds itself as an ELContext listener:
> // Add self as ELContextListener to the Faces App so we can add the
> // portletConfig to any newly created contexts.
> ApplicationFactory appFactory =
> (ApplicationFactory) FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
> Application app = appFactory.getApplication();
> app.addELContextListener(this);
> so that the following method gets called when a new ELContext is created:
> public void contextCreated(ELContextEvent ece)
> {
> // Add the portletConfig to the ELContext so it is evaluated
> ELContext elContext = ece.getELContext();
> // Only add if not already there
> if (elContext.getContext(PortletConfig.class) == null)
> {
> elContext.putContext(PortletConfig.class, mPortletConfig);
> }
> }
> However, it looks like this method is called by the JSP container (in Tomcat, this is called by JspApplicationContextImpl.createELContext()). So, the ELContext implementation passed in is the JSP container's ELContext, as opposed to the one created by PortletFacesContext. So, when the PorltetELResolver executes the following code in its getValue() method:
> case PORTLET_CONFIG:
> context.setPropertyResolved(true);
> return context.getContext(PortletConfig.class);
> It actually returns null, because it's checking the wrong context instance (in this case, it's checking the PortletELContext, as expected).
> I'm not sure if this is the expected behavior of the container, but it would explain by why the RI's FacesContextImpl doesn't call ELContextListeners directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.