Currently invalid effect and duration values are silently defaulted to default values.
Requirement from Mark: add logging when in ProjectStage.Development.

Done. (I actually don't like unnecessary logging cluttering up a program.)

M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\message\MessageRenderer.java#35594

Effects added for <ace:messages/>. However, the main problem still remains, after much (often sidetracked) discussion:

Given:

• A prev. set of msgs. for a client id
• A curr. msg. for the same client id not in prev. set

How can we distinguish between an "init" (non-existent prev. msg.) and a "change" (changed prev. msg.)? Just try filling in the conditions in screenshot-03.

Logic to distinguish between "init" and "change" done according to Mark's suggestion. Two-pass process. Required major rewrites. Summary:

Given an old list and a new list of messages for a component client id (or null for global messages): filter and render out common message texts; for all remaining message texts that are not in both lists, compare the lists by position (not message text). Any new position < size of old list are changed messages; any new position >= size of old list are new messages.

M: C:\svn\ossrepo\icefaces3\trunk\icefaces\samples\showcase\showcase\src\main\webapp\resources\examples\ace\message\message.xhtml#37033
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\messages\Messages.java#37033
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\messages\MessagesRenderer.java#37033

In showcase ace:message(s) demo, you can generate two different faces messages for a component: empty input or input same as input field label. (Read the demo description.)

New message is when previously there was no message (either initially or right after valid input); changed message is when previously there was another message. (E.g. first empty input then type field label as input.)

Effects should be different for new and changed messages. No effect any other case.

Or you can write your own test app. Follow the example code in the backing bean to generate whatever and however many faces messages you want.

SEVERE: java.lang.IndexOutOfBoundsException: Index: 2, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.remove(ArrayList.java:387)
at org.icefaces.ace.component.messages.MessagesRenderer.encodeEnd(MessagesRenderer.java:94)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:877)
at org.icefaces.ace.renderkit.CoreRenderer.renderChild(CoreRenderer.java:80)
at org.icefaces.ace.renderkit.CoreRenderer.renderChildren(CoreRenderer.java:64)
at org.icefaces.ace.component.panel.PanelRenderer.encodeContent(PanelRenderer.java:238)
at org.icefaces.ace.component.panel.PanelRenderer.encodeMarkup(PanelRenderer.java:135)
at org.icefaces.ace.component.panel.PanelRenderer.encodeEnd(PanelRenderer.java:73)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:877)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1826)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
at org.icefaces.impl.renderkit.RendererWrapper.encodeChildren(RendererWrapper.java:49)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:847)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304)
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:847)
at org.icefaces.ace.renderkit.CoreRenderer.renderChild(CoreRenderer.java:76)
at org.icefaces.ace.renderkit.CoreRenderer.renderChildren(CoreRenderer.java:64)
at org.icefaces.ace.component.panel.PanelRenderer.encodeContent(PanelRenderer.java:238)
at org.icefaces.ace.component.panel.PanelRenderer.encodeMarkup(PanelRenderer.java:135)
at org.icefaces.ace.component.panel.PanelRenderer.encodeEnd(PanelRenderer.java:73)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:877)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:312)
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:847)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304)
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:847)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304)
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:847)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1819)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822)
at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPartialViewContext.java:150)
at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:973)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1819)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:421)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)

When the first lifecycle created two FacesMessages A and B, and then the next lifecycle created the exact same two FacesMessages A, B, then the new/changed detection code was removing the FacesMessages from a list in the wrong sequence, so the indexes would shift and then be trying to access past the end of the list. Reversing the sequence of removal fixed it.

We should add regression tests that deal with the various scenarios of adding, removing and changing FacesMessages.

icefaces3 trunk
Subversion 37480