Uploaded image for project: 'RichFaces'
  1. RichFaces
  2. RF-11112

PartialViewContext#getRenderIds() implementation returns empty set


    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 4.0.0.Final
    • Fix Version/s: 4.5-Tracking
    • Component/s: component-a4j-core
    • Labels:
    • Environment:

      Win7 x64, Eclipse Helios SR2, JBoss AS 6.0.0 Final, RF 4.0.0 Final.


      During invoke action phase we would like to retrieve a list of partial render IDs for some specific preprocessing (resetting submitted values for the case they're embedded in another form). Those IDs are normally available by PartialViewContext#getRenderIds().

      PartialViewContext partialViewContext = FacesContext.getCurrentInstance().getPartialViewContext();
      Collection<String> renderIds = partialViewContext.getRenderIds();

      This works fine in combination with standard JSF components, such as <h:commandLink><f:ajax render="foo"/></h:commandLink> However, when a RichFaces/A4J command component is been used, such as <a4j:commandLink render="foo" />, an empty collection is been returned instead. Debugging learns that the ExtendedPartialViewContextImpl implementation stores them in componentRenderIds instead of renderIds and never returns it on getRenderIds() method. The ExtendedPartialViewContextImpl also doesn't seem to use renderIds in a sensible manner anywhere else.

      I believe that componentRenderIds really has to be renderIds instead.

      As far now, we workarounded this by accessing the componentRenderIds field using reflection.

      Collection<String> renderIds = partialViewContext.getRenderIds();
      if (renderIds.isEmpty() && partialViewContext instanceof ExtendedPartialViewContextImpl) {
          try {
              Field componentRenderIds = ExtendedPartialViewContextImpl.class.getDeclaredField("componentRenderIds");
              renderIds = (Collection<String>) componentRenderIds.get(partialViewContext);
          } catch (Exception e) {
              // Handle.

      However, this introduced a nasty dependency in our code.

        Gliffy Diagrams




              • Assignee:
                bleathem Brian Leathem
                bauke Bauke Scholtz
              • Votes:
                6 Vote for this issue
                9 Start watching this issue


                • Created: