more Hints on the Perfomance problems with AjaxPortletBridge and FacesContextImpl

After some investigation we found strange things:
First of all, the JavaServer Faces 1.2 Spec says:

getELContext
If the Collection returned by Application.getELContextListeners() is non-empty, create an instance of ELContextEvent and pass it to each ELContextListener instance in the Collection by calling the ELContextListener.contextCreated(javax.el.ELContextEvent) method

But not all Implementations of FacesContext are Spec conform.  JBoss 4.2.3 GA is delivered with the JSF Version called Mojarra which is the RI implementation of Sun. The facesContext of this Implementation does contain a getElContext method without a loop which calls contextCreated:

public ELContext getELContext(){
   assertNotReleased();
   if(elContext == null){
      elContext = new ELContextImpl(getApplication().getELResolver());
      elContext.putContext(javax/faces/context/FacesContext, this);
      UIViewRoot root = getViewRoot();
      if(null != root){
            elContext.setLocale(root.getLocale());
      }
   }
return elContext;
}

On the other hand the FacesContext delivered with the JBossPortletBridge and the FacesContext implementation of MyFaces are spec conform. They implement a loop which calls contextCreated of the bridge.

The high invocation count of FacesContext.getELContext() is caused by the UI base classes eg. UIComponent and UIViewRoot.
These classes are calling getELContext() very frequently and they are the root of most JSF Tags.
This is the reason for our abnormal cpu usage.

Unfortunately, we are not able to say which impact our empty implementation of contextCreated has. We don’t know which objects the ELContext need and for what.

Leave a Reply

Your email address will not be published. Required fields are marked *