Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.0.0-alpha-2
-
None
-
Windows XP, eXo WebOS 2.0, snapshot as of 12/8, Tomcat 6
Description
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)
}
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.