In the ace:accordionPanel example, we use a different technique - adding an onchange handler instead - and this doesn't have a problem:

<ace:accordion collapsible="true">
<ace:accordionPane title="My To Do List">
<h:selectManyCheckbox layout="pageDirection" selectedClass="selectedCheckBox" onchange="submit();">
<f:selectItems value="#

"
var="listItem"
itemValue="#

"
itemLabel="#

"/>
</h:selectManyCheckbox>
</ace:accordionPane>

Using the same technique (and removing the f:ajax tag) in ace:tabSet also works.

To narrow it down further, this is only a problem with Mojarra. With MyFaces, the use of f:ajax works fine. I've updated the environment information and the workaround to reflect this.

At this point, I can only speculate that there is a difference in the findComponent algorithm that accounts for this difference.

I've removed the f:ajax from the tabset.xhtml file and added the onchange="submit();" mechanism that we using in the accordion panel for the time being so that specific showcase demo works when running under Mojarra on Liferay.

It's possible that MyFaces is sending "@this" to the client to be resolved at submit time while mojarra is attempting to resolve "@this" server-side. It should be possible to determine if these are the strategies by looking at the network traffic.

From the code at the top of the stack, and the exception message, the problem is that some code has already converted @this to a clientId, and the clientId doesn't start with a colon, so it's being used as a relative findComponent String from the selectManyCheckbox, and so is failing the search.

From Mojarra's AjaxBehaviorRenderer:

StringBuilder ajaxCommand = new StringBuilder(256);
Collection<String> execute = ajaxBehavior.getExecute();
Collection<String> render = ajaxBehavior.getRender();
String onevent = ajaxBehavior.getOnevent();
String onerror = ajaxBehavior.getOnerror();
String sourceId = behaviorContext.getSourceId();
Collection<ClientBehaviorContext.Parameter> params = behaviorContext.getParameters();

// Needed workaround for SelectManyCheckbox - if execute doesn't have sourceId,
// we need to add it - otherwise, we use the default, which is sourceId:child, which
// won't work.
ClientBehaviorContext.Parameter foundparam = null;
for (ClientBehaviorContext.Parameter param : params) {
if (param.getName().equals("incExec") && (Boolean)param.getValue())

}
if (foundparam != null && !execute.contains(sourceId))

com.sun.faces.renderkit.html_basic.SelectManyCheckboxListRenderer.renderOption(
FacesContext context,
UIComponent component,
Converter converter,
SelectItem curItem,
Object currentSelections,
Object[] submittedValues,
boolean alignVertical,
int itemNumber,
OptionComponentInfo optionInfo)
at line 361 calls: RenderKitUtils.renderSelectOnclick(context, component, true); which adds the specific param that AjaxBehaviorRenderer is looking for.

So it looks like it comes down to if sourceId is specified, and is in the execute list. At this point, execute should consist of "@this".

The Mojarra jira for the issue:

http://java.net/jira/browse/JAVASERVERFACES-1579

Only h:selectManyCheckbox and h:selectManyListbox exhibit this problem, where if they are within 2+ levels of naming containers, and have an f:ajax tag, and are using Mojarra, that it will throw an excdption. It doesn't require portlets, but portlets will always fail since the portlet UIViewRoot is a naming container, and the selectMany* component need to be in a form, so you're already two levels deep. But you could just as well have a form and a dataTable or f:subview.

It doesn't matter what you specify to execute, because the mojarra code will add a bogus entry to the execute list.

Modified the ace:ajax rendering code to handle differences between ACE components, and regular h: components, so that it can also be used with h: components. So far only verified with the h:selectManyCheckbox from the test scenario.

This code varies noticeably between trunk and branch, so branch will require separate implementation and verification.

<f:subview id="testSub">
<h:form id="form">
<ace:tabSet id="sampleTabSet" clientSide="false">
<ace:tabPane id="toDoList" label="To Do List">
<h:selectManyCheckbox id="list" layout="pageDirection" selectedClass="selectedCheckBox">
<f:selectItems value="#

"
var="listItem"
itemValue="#

"
itemLabel="#

"/>
<ace:ajax execute="@this" render="sampleTabSet"/>
</h:selectManyCheckbox>

trunk
Subversion 28310

Since there's no real fix for this issue, aside from Mojarra fixing it, or using work-arounds, then we'll link to ICE-7909, which is a jira for making ace:ajax work with h: components, so that it can be used instead of f:ajax.

Subversion 28310 should have been made under ICE-7909.