A big thank you for posting this! Incidentally, I already spent the entire day on this trinidad validation mess. Backdrop: I had problems getting the Hibernate validator to work with the CVS-based Seam (solved in the meantime thanks to Pete Muir's helpful response): http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115318 So I thought: Why not use the JSF validators as temporary workaround? And then I noticed that the JSF validators fail to work correctly when Trinidad is involved. What's more, the Hibernate validator annotations don't work either in combination with s:validate all and Trinidad (one can test this by modifying Seam-discs). anonymous wrote : Any idea why this is not working? no real idea, but I debugged it and it looked to me as if it could be a state restoration issue. When the view tree is constructed during the first RENDER RESPONSE phase, the validator properties (attributes such as minimum or maximum) are stored. On a subsequent faces request, this state is supposed to be restored during the RESTORE VIEW phase. But it appears that this isn't working correctly. The culprit could possibly be org.apache.myfaces.trinidad.bean.util.StateUtils.restoreState() or a related method. StateUtils.restoreState() is called from org.apache.myfaces.trinidad.bean.util.FlaggedPropertyMap. | // org.apache.myfaces.trinidad.bean.util.FlaggedPropertyMap | public void restoreState( | FacesContext context, | FacesBean.Type type, | Object state) | { | StateUtils.restoreState(this, context, type, state, getUseStateHolder()); | } | | Until FlaggedPropertyMap.restoreState() is called, the restoration process looks ok to me (at least the argument named "state" correctly contained the validator properties). A Trinidad expert would need to look at this, where exactly the state restoration fails. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071413#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...