I might need some additional clarification here. There is documentation about a aui:form tag provided by Liferay:

http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Alloy+UI+Forms+(aui)
http://alloy.liferay.com/

But this doesn't appear to be a JSF tag from what I can determine. If that's the aui:form that is being used, then, since it's not a JSF component with a renderer, it's not going to be possible for ICEfaces to find it in the component tree.

Neil does allude to an aui:form as port of AlloyFaces. I'm not the familiar with it but it appears that this provides component JSF versions/wrappers of the tags provided by Liferay so that they are represented as actual components.

Within ICEfaces, code is added to the form by wrapping the FormRenderer in what we call a FormBoost. It's detected on wrapped using the following logic. Does

Renderer renderer = "javax.faces.Form".equals(family) ? new FormBoost(r) : r;

In this case, perhaps the aui:form renderer is not declared to be of the javax.faces.Form family? (I haven't checked the AlloyFaces source). If not, then the FormBoost would not be applied.

Without additional info or a test case, we'll have to close this case as won't fix. Is the workaround sufficient for this? Is there any additional information that can be provided about how you are using the aui:form - is it the Liferay tag or the AlloyFaces wrapper?

Sorry Deryk, I missed your first response. Neil Griffen (of the portletfaces bridge project) has started a JSF analog (using JSF UIComponents) to the JSP AlloyUI (the one you refer to with the link above). This is intended to map the styles such that they will be themeable using the same theme stylesheets as JSP pages would. Anyway, the project is called AlloyFaces, and the related forum post is this:

http://www.portletfaces.org/community/forums/-/message_boards/view_message/57547?_19_threadView=tree

For me, the workaround is enough, but it means i have to manually add all the additional styles that the AlloyFaces would have done automatically for me. In my opinion, ICEfaces should be able to see that it is a form (whether aui:form, h:form, or any other kind of form) and be able to augment it with the necessary information to make it work. I no longer have my test case as my project moved forward with the workaround, but this issue should not be hard to reproduce. Just create a maven web project, include jsf, alloyfaces, and icefaces. Put an aui:form in the page and an input that has an on change or something then see if icefaces can provide the automatic ajax. If it is necessary, I could probably put a small project together to demonstrate this. Please let me know.

I will ask Neil to take a look at this thread to see if he is doing something that makes it not a javax.faces.Form family component.

The AlloyFaces <aui:form> component is a subclass of UIForm.

See: http://svn.portletfaces.org/svn/portletfaces/alloy/faces/alloyfaces/trunk/src/main/java/org/portletfaces/alloy/faces/component/AUIForm.java
And: https://svn.java.net/svn/mojarra~svn/tags/2.1.3/jsf-api/src/main/java/javax/faces/component/UIForm.java

When ICEfaces fortifies form components, would it be able to find the AUIForm component in the tree?

Ok, then what is probably happening then is that our FormSubmit class (a SystemEventListener) is bailing due to:

public boolean isListenerForSource(final Object source) {
if (!(source instanceof HtmlForm))

The processEvent method for this class is the one that adds the script for capturing form submissions for Ajax purposes.

Changed the FormSubmit class to handle all form processing as UIForm types rather than HtmlForm types. This way we'll handle a broader range of alternate form implementations.