Using Seam s:validateEquality to compare two fields for equality

I sometimes forget about some of the built in Seam Converters and Validators. While working on a project recently I had a requirement that had two password fields. This was to ensure that the password was spelled correctly. Pretty standard stuff when registering a new user. When I got to this requirement I started to roll my own validator and then remembered Seam had already done this for me. Here is the code.

<s:decorate id="passwordField" template="layout/new.xhtml">
  <ui:define name="label">Password:</ui:define>
  <h:inputSecret id="password" value="#{user.password}" required="true" immediate="true" redisplay="true">
    <a:support event="onblur" bypassUpdates="true" ajaxSingle="true" reRender="passwordField"/>
<s:decorate id="verifyPasswordField" template="layout/new.xhtml">
  <ui:define name="label">Verify Password:</ui:define>
  <h:inputSecret id="verifyPassword" value="#{register.verifyPassword}" required="true" redisplay="true">
    <a:support event="onblur" bypassUpdates="true" ajaxSingle="true" reRender="verifyPasswordField"/>
    <s:validateEquality for=":#{rich:clientId('password')}" message="Passwords don't match." />

That is all there is to it. Pretty slick. Now when the user tabs or clicks out of the Verify Password field the two fields are compared for equality and if they aren’t equal a validation error is displayed so the user can be made aware that there was a spelling mistake.

One thing to keep in mind is that there is a bug in this validator and the way it finds the id. In the Seam documentation example it shows the following.

<s:validateEquality for ="password"/>

When I tried this it didn’t work.

After some digging around in the Seam forums I found a post explaining that this was a bug and needed to be changed to the following.

<s:validateEquality for=":#{rich:clientId('password')}/>

The s:validateEquality can not only check for equality but it can also check for not equal, greater than, greater than or equal to, less than, and less than or equal to. Check out the Seam documentation for the complete listing of attributes.

Seam redeployment loop to JBOSS AS 5.1.0

Today I was working on a Seam project and after modifying the pages.xml file and re-exploding to JBOSS the application server went into a loop and kept re-exploding over and over.

After some digging around I found out that it is a bug in JBOSS AS 5.1 and is being fixed in 5.2. Basically it is due to an Eclipse temp file being in either your WEB-INF/ or META-INF directory. The temp files to look for are either *.jsfdia or *.spdia and can be deleted. In my case the file was named pages.xml.spdia and was located in the WEB-INF/ directory along with my pages.xml file that was modified. After I deleted the file and re-exploded everything worked just fine.

a:mediaOutput is not compatible with a Seam long running conversation

Over the weekend I was working on a Seam project that required images to be uploaded so I took a look at the rich:fileUpload component. Looking at the RichFaces sample code it looked very straightforward and I assumed it would take just a couple of hours to implement. 2 days later I still couldn’t get it to work. I was so frustrated that I started questioning my intelligence. Fortunately I am stubborn, just ask my wife, and I refused to give up. This time it paid off. I finally found out via the Seam framework forums that the a:mediaOutput RichFaces component is not compatible with Seam long running conversations. The file was uploading fine and the listener method could see the object but when it came time for a:mediaOutput to paint the object to the screen it could not be found.

The solution was to simply add an s:conversationID component to a:mediaOutput so that Seam would know the conversation id. Once I added this everything worked fine. UGH! Below is an example.

<a4j:mediaOutput element="img" mimeType="#{file.mime}"
 createContent="#{fileUploadBean.paint}" value="#{row}"
 style="width:100px; height:100px;" cacheable="false">
  <f:param value="#{fileUploadBean.timeStamp}" name="time"/>  
  <s:conversationId value="#{}"/>

These are the kind of things that drive me crazy when programming. Things like this can totally blow a schedule out of the water.