[
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.
